> Notice that: > o sshd is written to re-parse sshd_config and launch and new process > on receiving SIGHUP. Yep. > o you expect disconnection from an ssh'd tty when root sends sshd the > signal to hangup. Ummm, no I don't. That's never been the way ssh has worked. ... > COMMAND PID USER FD DEVICE NODE NAME > sshd 344 root 3u 479 TCP *:ssh (LISTEN) > sshd 1158 root 4u 13436 TCP localhost:ssh->remote:52589 (EST) > sshd 1160 user 4u 13436 TCP localhost:ssh->remote:52589 (EST) > > o We have the real daemon listening, and the spinoffs handling my > connection via a highport and interface:ssh. > > This behavior is so far what I expect. > > Until: > You send SIGHUP to the original process; your connection remains. > > o The spunoff processes (not listening) continue like nothing > happened, a la: > $ `ps aux |grep sshd` > root 1158 0.0 0.6 5628 1716 ? S 17:56 0:00 /usr/sbin/sshd > user 1160 0.0 0.6 5648 1772 ? S 17:56 0:00 /usr/sbin/sshd > root 1184 0.0 0.5 2720 1384 ? S 18:20 0:00 /usr/sbin/sshd The server ssh process, #344, when it got the HUP forked off and reread the sshd_config, resulting in process 1184 above. Your existng two processes, 1158 and 1160 stayed alive. Which is what should happen, and always has happened. Killing the main ssh process (the one that does the initial accept on the network socket) has never killed off active user sessions. Else how could you upgrade ssh remotely? This would seem to be expected behaviour. -- Brian Hatch "Is there a Lawyer Systems and in the House?" Security Engineer **BLAM!** http://www.ifokr.org/bri/ "Any more?" Every message PGP signed
This archive was generated by hypermail 2b30 : Fri Jun 28 2002 - 19:01:00 PDT