Date: Mon, 14 Sep 1998 00:40:13 -0700 (PDT) From: Marc Slemko <marcs@znep.com> To: Andrew McNaughton <andrew@squiz.co.nz> Cc: freebsd-security@FreeBSD.ORG Subject: Re: sshd Message-ID: <Pine.GSO.4.02A.9809140032490.2858-100000@redfish> In-Reply-To: <Pine.BSF.3.96.980914184628.2128D-100000@aniwa.sky>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Sep 1998, Andrew McNaughton wrote: > > Rarely have I seen hung sessions, even after being rudely disconnected > > by the IPS(s) I connect into. Even then what's so diffifcult about > > killing the child? > > I've had problems after having my modem drop and redial. Mostly sessions > seem to survive this (with a fixed IP), but occasionally they haven't, and > I've been unable to create new connections to sshd until I've killed the > demon process of the crashed session. This has happened to me three > times, and in all cases I've had multiple sessions open and I've still had > a live connection which I've been able to use to retrieve the situation. > I can't say whether sshd recovers itself eventually, but it's not quick. That is a differnet issue and will happen if it is running from inetd or standalone. What is probably happening there is that your machine thinks the connection is dead, but the server doesn't know it thinks that since the connection was down when it began to think that. By chance (not random chance, of course) if your client decides to use the same client port, then its connection attempt will look like bogus data from the existing connection to the server. Until the server tries to send something (eg. keepalive) to the client and gets a RST, this will keep happening. The way around it is to just try sshing in twice at the same time; obviously, then one has to use a different port. If you had multiple sessions open, then you may need to do n+1 sessions to get in from the client. Randomized allocation of ports on the client side (a libc thing) would avoid this, and would certainly avoid the case where it keeps happening over and over due to deterministic port allocation by the client. There is a thread about this (not related specifically to ssh, IIRC) from some list (tcp-impl or end2end-interest I think...) that I should reference here, but my brain doesn't want me to go look it up. It is possible this was already changed in -current, don't know. Of course, this may not be your problem but it does sound like it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.02A.9809140032490.2858-100000>