I have ServerAliveInterval and in case of few machines also ClientAliveInterval set to 540 in SSH client/server configuration files (I suppose setting it to more than that would not be a good idea). I work with many SSH sessions which currently freeze after a few minutes.

How can I fix it? What I want is to have a session to not freeze at all, so that if I open a session at 8 and don't use it for 4 hours, for example, to still use it again at 12 without having to log-in again.

  • How long can you currently stay logged in (assuming this isn't due to network disconnection)? TCPKeepAlive yes? – iyrin May 4 '15 at 8:40
  • I am not sure but 10 min. at most. As for TCPKeepAlive yes - depends on the machine. – syntagma May 4 '15 at 8:44
  • 11
    Just use mosh? – Vi. May 4 '15 at 11:08
  • 2
    Or you could use autossh... – ThoriumBR May 4 '15 at 18:24
  • 1
    I'd say leaving a connection open for 4 hours is a security concern, and you should be using screen instead. But I'm still upvoting your question because I'm experiencing the same issue after only a minute or two. – Dale Anderson Aug 24 '16 at 17:22

The changes you've made in /etc/ssh/ssh_config and /etc/ssh/sshd_config are correct but will still not have any effect.

To get your configuration working, make these configuration changes on the client:


Host *
ServerAliveInterval 100

ServerAliveInterval The client will send a null packet to the server every 100 seconds to keep the connection alive

NULL packet Is sent by the server to the client. The same packet is sent by the client to the server. A TCP NULL packet does not contain any controlling flag like SYN, ACK, FIN etc. because the server does not require a reply from the client. The NULL packet is described here: https://tools.ietf.org/html/rfc6592

Then configuring the sshd part on the server.


ClientAliveInterval 60
TCPKeepAlive yes
ClientAliveCountMax 10000

ClientAliveInterval The server will wait 60 seconds before sending a null packet to the client to keep the connection alive

TCPKeepAlive Is there to ensure that certain firewalls don't drop idle connections.

ClientAliveCountMax Server will send alive messages to the client even though it has not received any message back from the client.

Finally restart the ssh server

service ssh restart or service sshd restart depending on what system you are on.

  • I think a high ServerAliveCountMax is also needed in order for this to be as reliable as possible. And if both ServerAliveInterval and ClientAliveInterval are set low enough, I don't think there will be any need for TCPKeepAlive. Additionally, if there are any middleboxes, they can still lose state even with all of the previously mentioned settings configured exactly correct. It may help to use MPTCP (if both client and server support it). – kasperd May 4 '15 at 20:28
  • It's not clear at the start whether you mean config on the client side or server side (eventually I conclude, client side). Then at ServerAliveInterval description, you say "client will send... to the server", but in the next paragraph "NULL packet is sent by the server to the client". I find these a bit confusing. – Craig McQueen Jun 11 '17 at 7:23
  • 1
    After adding to the server I get: /etc/ssh/ssh_config: line 57: Bad configuration option: clientaliveinterval /etc/ssh/ssh_config: line 59: Bad configuration option: clientalivecountmax – ajthinking Jul 29 '17 at 15:57
  • 3
    @Anders You get the error because ClientAliveInterval and ClientAliveCountMax are ssh server options, thus meant for sshd_config and not ssh_config – Valentin Bajrami Jul 30 '17 at 8:11
  • 1
    @chandresh you don't have to. After modifying ssh_config the new sessions will read that file. The /etc/environment file is a different thing which has the format of VAR="value" without spaces thus VAR = "value" would be invalid. Sourcing /etc/ssh/ssh_config that way will i.e read: Port 22 or Host * which will treat these as commands – Valentin Bajrami Aug 14 '19 at 12:38

Personal suggestion: use screen on the remote host; it will manage to keep your connection alive for as long as it stays active in a terminal.

Here's what I typically add to /etc/screenrc for quick identification of my screen sessions:

hardstatus alwayslastline
hardstatus string "%{= kG}[ %{G}%H %{g}][ %{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B}%Y-%m-%d %{W}%c %{g}]"
defscrollback 8192

EDIT : Hints.

The hardstatus string will show a bottom status line such as this one: Screen session example with three open tabs

The scrollback buffer is also extended to 8192 lines instead of the usual 1000-1500 (depending on the distribution).

  • Thanks, two questions: 1. Can you explain the options in you screenrc file? How do I configure the system the launch screen/tmux right after I login? – syntagma May 4 '15 at 9:12
  • 12
    Just to clarify, screen does not keep your ssh connection alive. It runs processes in a virtual terminal independent of the user terminal you connect to via ssh so the process doesn't rely on your connection. You will still lose your ssh connection until it's resolved. – iyrin May 4 '15 at 9:52
  • 1
    By "keep the connection alive" I essentially mean "prevents the connection from idling", which has the same result. If there's no input for 4 hours, SSH will go idle and eventually close the connection, all the child processes gone, too. – user86969 May 4 '15 at 11:46
  • 2
    As much as I loved screen, I advise new users to start with tmux. – dotancohen May 5 '15 at 7:10

If the problem is a hibernated laptop or a less-than-prefect network connection, I'd recommend using mosh which runs over ssh and allows automatic reconnecting.

From the website:

Mosh (mobile shell)

Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes.

Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Mosh is free software, available for GNU/Linux, BSD, macOS, Solaris, Android, Chrome, and iOS.

In combination with tmux (or the older screen), this allows me to connect via ssh to a server from my laptop and stay connected for days even when changing wifi connections and surviving mobile data drop-outs.


With OpenSSH:

You need to enable

TCPKeepAlive yes

both in your client ssh_config (e.g. /etc/ssh/ssh_config or in ~/.ssh/config) and your destination SSH server running OpenSSH (e.g. /etc/ssh/sshd_config).

So every time your connection idles, OpenSSH sends some dummy packet to your destination host...

  • This can also cause the connection to go down The default is ''yes'' (to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. ...this means that connections will die if the route is down temporarily, and some people find it annoying. linux.die.net/man/5/sshd_config – iyrin May 4 '15 at 8:55
  • Honestly, but "[…] network goes down […] client host crashes […] route is down […]" are severe errors no SSH configuration can catch. The main issue here are idle SSH sessions, not network failures. Therefore to sum it up: - enable TCPKeepAlive yes in both server and client. - set ClientAliveInterval on the server - set IdleTimeout on the server - set ClientAliveCountMax That should do the trick... – Martin Allert May 4 '15 at 9:48

Check your sshd configuration on the host machine /etc/sshd_config for the IdleTimeout setting.

IdleTimeout time
Sets idle timeout limit to time in seconds (s or nothing afternumber), 
in minutes (m), in hours (h), in days (d), or in weeks (w).If the 
connection have been idle (all channels) for that long time thechild 
process is killed with SIGHUP, and connection is closed down.

A little hack I use if it's not possible to use screen, or edit the hosts ssh server settings, or any of the good and proper suggestions above...

Just run top whenever you are going to leave the session alone.

Generally that'll keep it alive indefinitely, although, as others have mentioned, that might not always be wise vis-a-vis security!


In my case problem was in large MTU size. You can change MTU on router if you using NAT, but I change MTU on server:

sudo /sbin/ifconfig eth0 mtu 1036
sudo /etc/init.d/networking restart

For me, the SSH connection used to hang up.

The below solution worked for me. Now the SSH connection always stays live.

From the server:

  1. Edit the file at /etc/ssh/sshd_config
$ sudo vi /etc/ssh/sshd_config
  1. Add or enable this line in the file.
ClientAliveInterval 60
  1. Save the file and restart the sshd service
$ sudo service sshd restart

From the local machine/client:

  1. Edit the file at /etc/ssh/ssh_config
$ sudo vi /etc/ssh/ssh_config
  1. Add this line to the file.
ServerAliveInterval 60
  1. Save the file

About these Parameters :

ServerAliveInterval: number of seconds that the client will wait before sending a null packet to the server (to keep the connection alive).

ClientAliveInterval: number of seconds that the server will wait before sending a null packet to the client (to keep the connection alive).

Important: Whenever any modification is performed on a Production instance, please ensure to create a backup.

  • 1
    This is in essence the same as accepted solution. – ibuprofen Jun 15 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.