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 > > > > _______________________________________________ > > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > > tclug-list at mn-linux.org > > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list