Many NAT firewalls or VPN server time out idle sessions after a certain period of time to keep their trunks clean. Sometimes the interval between session drops is 24 hours, but on many commodity firewalls, connections are killed after as little as 300 seconds, and this can be a problem if you are working on a remote machine and suddenly you find yourself logged out with a message “Connection reset by peer”.
In a former article I’ve presented autossh, a solution that comes to your help when you want to be sure that a SSH connection stay always on between 2 machines. Autossh is a simple program that allows you to run an instance of ssh, keep it under control, and restart the same instance once that the connection is dropped up to a maximum number of times controlled by an environment variable.
This is useful if you need to have a “permanent” connection between 2 machines, but perhaps you just need to have a connection between your personal computer and different servers, and in these cases autossh is less useful, so let’s see how to use some openssh options to keep our connection open.
With openssh it’s easy to keep a connection “alive” sending a packet every n seconds, this is controlled by 2 parameters: ServerAliveCountMax and ServerAliveInterval.
ServerAliveCountMax
Sets the number of server alive messages (see below) which may be sent without ssh receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session. The server alive messages are sent through the encrypted channel and therefore will not be spoofable. The server alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive.
The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds. This option applies to protocol version 2 only.
ServerAliveInterval
Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server, or 300 if the BatchMode option is set. This option applies to protocol version 2 only.
Set it client side
To enable the keep alive options system-wide (root access required), you should edit the file /etc/ssh/ssh_config and add these options:
Host * ServerAliveInterval 300 ServerAliveCountMax 3 |
As alternative you can also set the settings for just your user, editing the file (or create it if it doesn’t exist) ~/.ssh/config , the options are exactly the same.
Set it server side
You can also make your OpenSSH server keep alive all connections with clients by adding the following to the file /etc/ssh/sshd_config:
ServerAliveInterval 300 ServerAliveCountMax 3 |
These settings will make the SSH client or server send a null packet to the other side every 300 seconds (5 minutes), and give up if it doesn’t receive any response after 3 tries, at which point the connection is likely to have been discarded anyway.
Popular Posts:
- None Found
It seems that the ServerAliveInterval & ServerAliveCountMax sshd options are available on Ubuntu 12.04. I looked at the sshd_config man page first, and didn’t see anything about those options, but I tried it anyway on my home server. After restarting ssh, I was locked out – sshd failed to start.
The man page for sshd_config on my Arch desktop shows those options, so maybe it requires a newer version of ssh. In any case, just a warning . . . although I’m sure everyone is smart enough not to change the sshd_config on a remote machine (without another way to access it).
Thanks,
I’ll verify that on my Ubuntu at home (12.10).
DR, On the server side, you would be looking for “ClientAliveInterval”. For “ServerAliveInterval” look on the client side, that would be the man page for ssh_config.
About getting locked out, there are several things to try. One is to have a back up copy of the known good sshd configuration and have “at” call sshd pointed at the good config file. Another is to try a test run of the configuration using sshd’s extended test mode (-T). That won’t catch everything that will lock you out, but can help.
Slow Snail,
I am glad I saw your post indicating I need ClientAliveInterval on the server and vice versa, that kept me from making that mistake.
Luckily I also found out the init.d script in Debian does a check_config before doing a restart. So a typo or something like switching client / server options does not lock me out. 🙂
You said :
Set it client side in the file /etc/ssh/ssh_config
Host *
ServerAliveInterval 300
ServerAliveCountMax 3
Set it server side in the file /etc/ssh/sshd_config:
ServerAliveInterval 300
ServerAliveCountMax 3
but i think it should be
ClientAliveInterval 300
ClientAliveCountMax 3
in the file /etc/ssh/sshd_config.
We set client interval in server side config file that is /etc/ssh/sshd_config and We set server interval in client side config file that is /etc/ssh/ssh_config.
BTW thanks for such a useful info.
Elex is right. On the server (in sshd_config) it’s ClientAliveInterval. Using ServerAliveInterval in sshd_config will produce an error and cause sshd to not start. Then you lose your connection to your SSH server and can no longer access it remotely.
And this really sucks if your SSH server is hours away, like mine…