i'm blaming wiring because my ssh connections occationally "go dead" even within 30 seconds of opening the connection. and hence i doubt it makes sense in my case to blame the firewall, unless perhaps the firewall could be blamed for poor error recovery behaviour. addl info you asked for: openssh-3.9p1-8.RHEL4.4 & kernel-2.6.9-11.EL (centos 4) on both ends, actiontec/qwest/cpinternet in minneapolis on one end and actiontec/qwest/msn in st paul on the other end, nat on both ends, but all that was the same before moving house when there was no problem, i brought the same actiontec with me, and now these problems, hence again i blame the wiring, or perhaps different equip at the CO. but back to my original point, even with bad wiring, i think there's room for improved robustness either in ssh and/or in the kernel networking code. i envision that with better error recovery, i shouldn't be needing to open new connections even if packets get lost or whatever is happening. if any of you know any folk interested in testing that sort of code, i'd be happy to help by providing access.. Justin Krejci wrote: > This is especially true for NAT'ed clients/servers. The NAT mapping will > eventually expire when there is no activity, though that doesn't sound like > the case in this scenario if the connections start working again. I have > never ever had this problem before so I would imagine you have some odd > circumstances. I use SSH all day every day over the internet and local > ethernet network at home and at work. > > It would help if you provided some additional info like where you are > connecting from and to and with what software. Are you going from Windows to > a Linux box? Or vice versa. Are you using OpenSSH or PuTTy? Is the connection > over all ethernet in your house with only a switch or is it going out onto > the internet? > > Also, how long do the connections normally last before they stop working? Does > it happen after a long period of inactivity? How long do they stop working > before they start working again? > > On Wednesday 12 October 2005 01:44 pm, Dan Rue wrote: >>I've dealt with similar symptoms before and I've generally come to the >>conclusion that it's a crappy firewall between hosts. I managed to >>solve the problem, for my users at least, by setting this in my >>sshd_config: >> >>ClientAliveInterval 300 >> >>>From man sshd_config: >> >>ClientAliveInterval >> Sets a timeout interval in seconds after which if no data has >> been received from the client, sshd will send a message through >> the encrypted channel to request a response from the client. The >> default is 0, indicating that these messages will not be sent to >> the client. This option applies to protocol version 2 only. >> >>Going by what taht says, and the fact that it solves the problem for me, >>I figure that some firewalls will drop state during idle ssh sessions. >>And like I said, ClientTAliveInterval fixed it for my users that were >>having the same symptoms. >> >>Anyway, it's worth a try before rewiring your house :) >> >>Dan >> >>On Wed, Oct 12, 2005 at 01:29:20PM -0500, greg wm wrote: >>>hi, >>> >>>i think there's room for improvement in the way either ssh or the linux >>>kernel handles error recovery. >>> >>>my ssh connections frequently "go dead". after many minutes, or hours, >>>one of these "dead" connections may well "wake up" again. >>> >>>in the meantime, opening fresh connections to the very same machines is >>>almost never a problem. >>> >>>hence when one of the newer connections "goes dead", i can open up an >>>even newer one, or often, resume using one of the older ones that has >>>come alive again. >>> >>>it's likely that the immediate cause of all this is bad wiring in my >>>house. and qwest, in their famous molasses fashion, is likely to get it >>>sorted eventually. >>> >>>in the meantime i'd say there's a golden opportunity here if someone out >>>there responsible for error recovery code were interested in doing some >>>testing using my nice bad connection testbed. i could imagine it being >>>applicable either at the ssh app level or kernel networking level. if >>>anyone "has connections" with any such folk, or otherwise thinks this >>>might be worth pursuing, i'll be happy to cooperate.. >>> >>>greg >>> >>>Greg Whitley Mott >>>IT Coordinator >>>NonviolentPeaceforce.org