Hi all,
Here is my scenario: I have a bunch of Linux machines that automatically connects to my main server (using private keys, no password, without an interactive session) and creates a bunch of tunnels (local and remote, using the ssh option -L and -R). The ssh server contains all the public keys of all those machines in its own authorized_keys file.
In short my problem is that I need to know (on the SERVER) exactly when one of those machines connects and when it disconnects (because of any reason).

I have tried several mechanisms, but I haven't found the magic one that works reliably all the time.
Here is a list of attempts:

#1: (the one that so far works the best)
I wrote a C program that install signal handlers for all the SIGQUIT, SIGINT... that:
A: when it starts, it records on my logging system that a client connected, and
B: enter in an infinite loop: for(; sleep(10000);
B: when the signal handler is invoked, logs that the client got disconnected
This program is invoked from the authorized_keys through the "command=" option.
My authorized_keys file is something like this:
command="/usr/local/bin/updown Server1" ssh-rsa 786A786786B....
command="/usr/local/bin/updown Server2" ssh-rsa AAAAAABBBBB....
command="/usr/local/bin/updown Server3" ssh-rsa BCCCDD6768...
...

So, with that configured, the remote machine connects, and correctly invokes my updown app that records argv[1] (the machine name as specified on the authorized_keys file) on my log file and when it's stopped, it records its disconnection.
So far so good.
Unfortunately this doesn't work all the time. I've noticed that if the connection is dropped from the CLIENT side (by killing my ssh), everything works fine, but after letting it run for some time, I've seen some machines that are physically disconnected, but the updown process still running, *OR* the process is dead but there are no log events of this disconnection (my take is that it was killed with a SIGKILL that cannot be caught).
Any idea why my process was killed with a SIGKILL? How do I identify this situation?

#2: I tried to invoke the "updown" program from the CLIENT when ssh is invoked. This is even worse, because if I stop my ssh client the updown program still run on my server.

#3: I tried to parse the sshd log (/var/log/secure) but that won't work for me because I can't really identify the machine by looking at the log (they are all behind the same NAT, so from the server point of view, they all arrive from the same public IP).

Any idea?
Is there a way I can tell sshd to run a command when a client connect and another command when the client disconnect?
I haven't found anything and I don't know where to look at this point.
If any of you have an idea, hint, suggestion, that would be great.

-- Zanz

Have you thought about using .bash_profile and .bash_logout to execute commands? Since the ssh client should be logging in and out when it connects/disconnects, this might be an approach.

That's an idea... For scalability reasons I don't like the client machines to open a bourne shell, but it's at least something to try.
Thanks for the suggestion.
-- Zanz

OK, I can see that being a valid objection. Perhaps an SSH two-step? Whenever the automatic connection starts from the client, it first executes a command, then logs in:

Then run a logout script after the connection is done.

I'm assuming that the clients are running SSH via some sort of script anyways from what you've posted, and I think that if a disconnect occurs for any reason, the script on the client side should move to the next command and run the "logout" script.