[prev in list] [next in list] [prev in thread] [next in thread] 

List:       secure-shell
Subject:    RE: sshd doesn't notice that a client has disconnected
From:       Tony Plastino <TonyP () freerange ! com>
Date:       1999-02-19 17:28:30
[Download RAW message or body]

I have found at least an interim solution.  Require all shells to have a
timeout function, and set it to some reasonable timeperiod.  This is
something I should have instituted anyway, but for "trusted" environments,
with developers that need to maintain long sessions with periods of up to a
half an hour or more of idle time, this is not reasonable.  Just one more
thing to agitate the general user community with.

Under Solaris, even though you have the option of setting TIMEOUT=n in
/etc/default/login, it does absolutely nothing to the standard /bin/sh--it
doesn't repect that setting.  So, I have had to make the default shell ksh,
and go as far as requiring either ksh or some other shell that repects the
timeout, and craft a policy (one more to enforce) requiring users not to
unset the limits.

It would be much much better though if SSH2 would simply be aware of the
situation and do something about it.

Moreover, in the man pages, it states that at some point in time (read "not
yet implemented") the sshd will be able to utilize a "keep alive" option
that will constantly try to detect if the client is still there, and
resetting the connection if the link has gone down.  This has been in the
man page for quite a while now, and it pains me to see the enormous amount
of features that are supposed to be distinguishing that are "not yet
implemented"  

I personally feel ripped off.  SSH1 was great stuff, and 1.2.26 seemed to be
very very stable.  But there is absolutely 0 commercial support for it
anymore, and in order to get commercial support, we are forced to use this
jejune substandard protocol that is only half of what it was purported to be
in the first place.

I resent the practice of holding the commercial community captive and using
it as a research monkey, a concept brazenly put forth by 'Billy and the
Borg', and now being capitalized on by the Finns.

enough of that though.  Let's just hope the SSH2 crew will get these things
implemented and into a release--SOON.

/* all opinions expressed by me are mine alone, and I am in no way speaking
for my employer when voicing them */
Anthony R. Plastino III
Internet Security Engineer
Free Range Media - 1 800 570 3873
http://www.freerange.com/

> -----Original Message-----
> From:	Leo Cyr [SMTP:lcyr@idesystems.com]
> Sent:	Thursday, February 18, 1999 4:55 PM
> To:	Tony Plastino
> Cc:	'ssh@clinet.fi'
> Subject:	Re: sshd doesn't notice that a client has disconnected
> 
> 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/
> > 

[prev in list] [next in list] [prev in thread] [next in thread]