Unfortunately I don't know how to fix it, but I've seen the same thing with a RedHat 5.1 (kern. 2.0.35) server running sshd2 from the 2.0.10 source. I've seen it when connecting from another linux client or 95/NT FSecure ssh2 client. I also need to fix this -- it gets to be a pain to clean up after every lost session over an IP Masqueraded link! On Thu, 18 Feb 1999, Tony Plastino wrote: > Some background: > > Solaris 2.5.1/2.6 server/clients running either 2.0.11 or 2.0.12 and 1.2.26 > (for backwards compatibility) > Datafellows TnT 2.0.9 or 2.0.10(build 3) NT clients. > > The following problem has been persistent throughout my use of SSH2 (I went > from 1.2.26 to 2.0.10). > > A SSH2 client (either NT or Unix) makes a connection to the server. > The client closes abnormally (link goes down or some other termination other > than "exit" or ^D) > That client will not be able to establish a new connection--period > > One must log into a different machine, then ssh to the server, do 'ps -ef | > grep pts' and kill the offending sessions. They typically look like: > > billy 16305 16301 0 10:38:25 pts/0 0:00 -sh > billy 16377 16305 0 11:25:31 pts/0 0:00 -ksh > root 16403 16399 0 10:48:25 pts/1 0:00 -sh > root 16478 16477 0 11:45:31 pts/1 0:00 ps -ef > root 16477 16403 0 11:45:31 pts/1 0:00 -ksh > > and in this case, the client on pts/0 has died, but neither "who" nor > "netstat" will show that the user is connected. Therefore, as I see it, the > sshd should have killed the sessions. This is not the case. Only when I > use > > "kill -9 16377 16305" will the daemon let go and allow the client to log > back in. > > Has anyone else run into this? If so, how did you fix it. Thanks in > advance, > > Anthony R. Plastino III > Internet Security Engineer > Free Range Media - 1 800 570 3873 > http://www.freerange.com/ >
