Howto prevent SSH from being affected by broadband modem timeouts
For a long time now I’ve suffered through a modem which disconnects any TCP session which has been idle for 15 minutes. For the most part this behavior is not problematic, except for SSH. I’ve gotten into the habit of trying to leave all of my remote SSH sessions running a program with continuous feedback such as top, htop, saidar, iftop, or watch. Of course there are plenty of times in the middle of work I don’t think to run a program and do some research only to come back to a dead SSH connection. I decided to finally address this issue and figure out how to send some sort of keep-alive. There are 2 options which can be used: ServerAliveInterval and TCPKeepAlive. Each of these can be used alone or together but there are benefits and drawbacks to each.
- ServerAliveInterval is not spoofable but will disconnect the session if ServerAliveCountMax keep-alive messages are sent without a response.
- TCPKeepAlive is set to ‘yes’ by default so that the client will notice TCP connection problems. TCPKeepAlive packets can be spoofed but I’m not sure if that is a serious problem.
It seems as though a combination of the 2 options is best, though the documentation warns that route problems can cause connections to be reset. I’m not sure if that’s a serious problem but I can address it if it comes up.
For now I’m trying these settings:
- ServerAliveInterval 60
- ServerAliveCountMax 5
- TCPKeepAlive yes
This has solved my problems with ssh sessions getting timed out by my DSL modem. Hopefully there will be no unwanted side-effects.
Why not just use screen? It
Why not just use screen? It allows you to reconnect to a terminal session even if your connection is terminated. Its great.
The versatility of SSH
Screen would be an ok solution if I was only concerned about saving my shell sessions. It is still less convenient to be disconnected and have to reconnect than to not be disconnected at all. But I do use screen or dtach often when running commands for the purpose of preserving the session.
However, screen does not help at all when it comes to the frequent use of SSH to do port forwarding. Instead of VPN setups which can become cumbersome with multiple clients I choose to make sure all of my clients have an on-site machine that I can connect to using SSH and then forward the ports necessary to access on-site services. Before implementing this I had to connect via SSH and then run a command to keep transmitting data such as some form of "top" (top, atop, htop, iftop) or watch. After making these changes I can simply connect via SSH and access forwarded ports without the connection going down in 15 minutes of inactivity in using those ports.
I would suggest that a combination of screen or dtach and these settings are truly an ideal configuration.