SSH timeout prevention – keep SSH sessions alive

SSH timeout due to inactivity is annoying. Here’s how to keep your SSH sessions alive and prevent the SSH timeout:


By sending a “null packet” between the client and the server at a specified interval that is smaller than the timeout value, we can avoid SSH timeout. It doesn’t matter if the packet is sent from the client or the server, as long as there is some communication going on between the two.

If you setup your SSH client to send the “null packets”, you’ll prevent an SSH timeout on all the SSH connections you make from your computer. If you are annoyed with your own SSH sessions timing out when you’re connected to servers, this is what you want to do.

If your clients (customers, users, kids) are fed up with the SSH timeout, you can either instruct them on how to configure their SSH clients – like pointing them to this article – or you can configure the server itself to avoid SSH session timeout. To do that, you setup the SSH server to send the “null packets”, and you’ll prevent a timeout on all the SSH connections every client makes to the server.

Fortunately, the setups are not exclusive, so you may setup both your client and all your servers and everything will run smoothly.

Prevent SSH timeout on the client side

If you’re on Mac or Linux, you can edit your local SSH config file in ~/.ssh/config and add the following line:

ServerAliveInterval 120

This will send a “null packet” every 120 seconds on your SSH connections to keep them alive.

Prevent SSH timeout on the server side

If you’re a server admin, you can add the following to your SSH daemon config in /etc/ssh/sshd_config on your servers to prevent the clients to time out – so they don’t have to modify their local SSH config:

ClientAliveInterval 120
ClientAliveCountMax 720

This will make the server send the clients a “null packet” every 120 seconds and not disconnect them until the client have been inactive for 720 intervals (120 seconds * 720 = 86400 seconds = 24 hours).

Published by Bjørn Johansen

Bjørn has been a full-time web developer since 2001, and have during those years touched many areas including consulting, training, project management, client support, and DevOps. He has worked with WordPress for more than 16 years, and he is a plugin author, core contributor, WordCamp speaker, WordCamp co-organizer and Translation Editor for Norwegian Bokmål.

34 Comments

    1. Sure, if you make changes to your SSH daemon config, you’ll have to restart the SSH daemon to apply the new configuration :-)

  9. Thank you very much! It helped me to solve trouble with Unison synchronization.
    Config “~/.unison/doc.prf”:
    # Unison preferences
    label = Syncronize my documents
    root = /store1/MyDocs
    root = ssh://[email protected]//work/documents
    sshargs = -o ServerAliveInterval=15

  12. Something to point out, in your instructions for the server side configuration, there are formatting tags which I accidentally copy and pasted into my SSHD config and subsequently broke my SSH service on restart. Novice oversight on my part but it is easy to mistake that as being one line of configuration.

  15. also you should really stop using wordpress, its an awful platform. it butchered my comment so i can’t even tell you what the problem is with your config example

    php is bad and wordpress is the worst thing ever made in it

    1. OK, thanks for letting me know. I didn’t know it was so bad. What do you suggest I use instead?

        1. AFAIK, Medium doesn’t have a self-hosted version where I will own my own data, and can mess around and play with all parts of it. Except for a decent editor, it is also very limiting.

          Why would anyone recommend Medium over WordPress, BTW?

  19. I always did this on PuTTY. But when I switched to using cygwin/mintty, the ssh connections would always timeout. Thanks for the tip.

  21. lol the WordPress comment, haha
    And thank you so muchfor the timeout tip, I was going crazy.

  22. According to the sshd_config man page, ClientAliveCountMax is the number of dropped messages, not the number of seconds. It gives the example: “If ClientAliveInterval is set to 15, and ClientAliveCountMax is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds”.

    1. That’s what it says on this page as well:
      ClientAliveInterval is the number of seconds per interval, and ClientAliveCountMax is how many intervals we’ll count before dropping the connection.

Comments are closed.