Hi, I am facing this problem with sshing into another system. What I am doing is: ssh root@192.168.61.136 Now, this prompts me for password and let me login to 192.168.61.136 where sshd is running. Now, I open up another temrinal window of my local machine and do: ps -eaf | grep ssh This shows the ssh session opened with 192.168.61.136 machine. Now, I open a terminal window of 192.168.61.136 machine and reboots the system. NOTE: on this machine sshd is running. Now, ideally since 192.168.61.136 is gone down, the process table should have the entry for ssh session deleted. BUt on doing ps -eaf | grep ssh on my local machine, I still see the ssh session process running. I dont know if its a bug or not. Kindly update me on this. Thanks, Sumit
You reboot the server, ie the one that sshd is running on, and the sshd process survives? Short of some kind of external checkpointing software, I don't see how that's possible. In its normal configuration, sshd will start as a listening process, ie there will always be at least one sshd even if nobody has logged on via ssh. This is normal. On a system that supports setproctitle (which Linux does) you will see something like this in the process table: # ps -eaf | grep sshd root 25072 1 0 Apr06 ? 00:00:01 /usr/sbin/sshd root 26965 25072 0 Apr09 ? 00:00:00 sshd: dtucker [priv] dtucker 26967 26965 0 Apr09 ? 00:00:07 sshd: dtucker@pts/0 In this example there is one login via sshd. Process 25072 is the listening daemon, 26965 is the privileged process that looks after my login and 26967 is the one that does most of the work for me. In its normal configuration, sshd is not like, eg, telnetd which is started from inetd. It's possible to configure sshd to run from inetd but it's not normally done that way (mainly because it's slower).
I'm not sure I understand this problem either: are you complaining that the client hangs when the server goes away? If you reboot the server forcefully, it may not gracefully close the connection and the client may stick around until TCP times out (potentially a very long time). You can mitigate this by ensuring that the server terminates the sshd processes gracefully (SIGINT or SIGTERM) or by setting a ServerAliveInterval and ServerAliveCountMax in your client config. Either way, this is not a problem in OpenSSH.
Close resolved bugs after release.