I'm looking for other people who are having trouble maintaining idle SSH sessions.
Recently RoadRunner replaced our router at one location, and since then idle sessions lock up in three to five minutes. As far as I know, there was no change on any of the systems involved. SSH clients and daemons are largely set to default configurations. Sessions within the site do not lock up, and sessions between other sites still behave as expected.
I AM NOT LOOKING FOR HELP READING THE SSH MAN PAGES! I am aware that there might be solutions in using UDP keepalive signals and other options, but what I want to do is confirm what's happened so I identify the reason and return things to their previous function.
I am looking for other people who have EXPERIENCED this change, or who have heard about it happening to someone else. I want to identify what we may have in common with other sites where this has happened.
Thanks, Jonathan
Jonathan Hutchins wrote:
I'm looking for other people who are having trouble maintaining idle SSH sessions.
As a Linux company with clients all over the geographic North America, we do a lot of SSH'ing. I'll risk sticking my networking foot in my mouth and say that I've found that certain network hops close idle TCP connections after a variable amount of time. By default, sshd does send TCPKeepAlive requests at regular intervals but it's possible that these are being ignored / discarded. The solution is to enable ClientKeepAliveInterval in your /etc/ssh/sshd_config on all the servers you connect to. I've found that a setting of 5 has worked everywhere.
On Tuesday 07 December 2004 12:01 pm, Jason Clinton wrote:
The solution is to enable ClientKeepAliveInterval in your /etc/ssh/sshd_config on all the servers you connect to. I've found that a setting of 5 has worked everywhere.
This does solve the problem. I didn't have any luck with the RR techs - they wouldn't even forward me to second level this time.
Oh my! Did the temperature in hell just drop below 32F? ;-)
Jonathan Hutchins wrote:
On Tuesday 07 December 2004 12:01 pm, Jason Clinton wrote:
The solution is to enable ClientKeepAliveInterval in your /etc/ssh/sshd_config on all the servers you connect to. I've found that a setting of 5 has worked everywhere.
This does solve the problem. I didn't have any luck with the RR techs - they wouldn't even forward me to second level this time.
Jonathan Hutchins wrote:
I'm looking for other people who are having trouble maintaining idle SSH sessions.
Recently RoadRunner replaced our router at one location, and since then idle sessions lock up in three to five minutes. As far as I know, there was no change on any of the systems involved. SSH clients and daemons are largely set to default configurations. Sessions within the site do not lock up, and sessions between other sites still behave as expected.
Does RoadRunner manage the router in question? If so, have you asked them what the currently-configured NAT entry timeout is for TCP sessions?
Does this only affect SSH, or does it affect other protocols, e.g. FTP, VNC, or Remote Desktop?
On Tue, December 7, 2004 12:05 pm, Gerald Combs said:
Does RoadRunner manage the router in question?
Yes.
If so, have you asked them what the currently-configured NAT entry timeout is for TCP sessions?
I've spoken to a clueless first-line tech who couldn't tell me anything.
Does this only affect SSH, or does it affect other protocols, e.g. FTP, VNC, or Remote Desktop?
I really only use ssh, so I can't be sure.
Once again, it was working, they changed the router, now it's broken. I'll probably call again today.
Jonathan Hutchins wrote:
Does this only affect SSH, or does it affect other protocols, e.g. FTP, VNC, or Remote Desktop?
I really only use ssh, so I can't be sure.
Once again, it was working, they changed the router, now it's broken. I'll probably call again today.
The reason I asked about other protocols is that it helps to establish the case that the Fruit^H^H^H^H^HNetopia is at fault vs your particular SSH client. The difficulty lies in that most other protocols don't normally have long idle periods like SSH. Of course, this may not matter if you can't get past front-line support.
On Tuesday 07 December 2004 02:43 pm, Gerald Combs wrote:
The reason I asked about other protocols is that it helps to establish the case that the Fruit^H^H^H^H^HNetopia is at fault vs your particular SSH client.
True, it's a good idea for eliminating clients. One of the reasons I've asked is to rule out particular versions of (gentoo) SSH clients, since mine are pretty stable.
Again, the clients didn't change, they had worked before the router change and now they don't. There _might_ have been a change in the specific version number on the Gentoo systems at this site, but I note that they don't lock up on local sessions, only on sessions to or from outside hosts.
The difficulty lies in that most other protocols don't normally have long idle periods like SSH. Of course, this may not matter if you can't get past front-line support.
Yeah, the closest I come is I'll sometimes minimize a Konqueror windows that's got an FTP link to another server, but I think that it will re-establish the connection invisibly if it gets dropped, so that's not a good test. Other than that, having learned on paid-by-the-second connections I'm compulsively diciplined about closing a connection as soon as I'm done with the task I opened it for. (I remember when we upgraded from the accoustic coupler to a direct connection and went to 56 Baud (NOT 56K).)
-
Gerald Combs -
Jason Clinton -
Jim Herrmann -
Jonathan Hutchins