This problem can be as annoying as a swarm of nats (which have been plaguing me at my house and work for the last week). For the typical cause, however, the solution is relatively simple.
The problem usually occurs due to a NAT router removing the connection from it’s connections table after a certain period of inactivity between the local and remote hosts. The router doesn’t realize the connection is still valid.
Assuming a typical Linux openssh config, add the following to lines to your
/etc/ssh/sshd_config file, then restart your ssh server:
The first line tells the ssh server to send a message to the client after 30 seconds of inactivity (change the number to fit your needs). This has the side effect of letting your router know there is still a connection between the two hosts.
The second line tells the ssh server to give up after sending 5 messages without getting a reply from the client (which it will, as long as the client is still connected).
“Wait!” you say, I don’t have access to the ssh server config file. Life sucks for you. Seriously, try this. Create or open your ~/.ssh/config file on the client computer, then add these lines:
This tells the client to send the same type of are-you-there message to the server as the server would to the client if you had set the ClientAliveInterval. (Full disclosure: I haven’t tested this solution.)
Another Cause of the Problem (and Solution)
I’m only hypothesizing here, but if you have
TCPKeepAlive="yes" set in the server config, you may continue to experience drops. This config directive tells the server to send tcp keep-alive messages to the client, which, I believe, are more sensitive (or sent more often), and will result in a disconnect if there is even a quick burp in your network connectivity. If you sent the server directives above, the server will close a severed connection after
ClientAliveCountMax seconds anyway, I think you can shut this off (set to “no”). Again, *I have not tested this, but it seems logical to me.*