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:
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).
Thank you so much! This is what I needed to know!
Thank you. This has been bugging our team for some time.
Awesome, thanks for all the great articles!
Thanks Bjorn you de man
sudo service ssh restart
Sure, if you make changes to your SSH daemon config, you’ll have to restart the SSH daemon to apply the new configuration :-)
or “sudo /etc/init.d/sshd restart” under gentoo.
i tried as you posted ,but it didn’t work.
“sudo service ssh reload” might be enough ;)
Thank you very much! It helped me to solve trouble with Unison synchronization.
# Unison preferences
label = Syncronize my documents
root = /store1/MyDocs
root = ssh://[email protected]//work/documents
sshargs = -o ServerAliveInterval=15
is there some content repeated in the third and fourth paragraphs?
Yeah, something weird had happened there. Thank you for notifying me!
Didn’t work on Mac client for me.
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.
pro tip – always make a backup of the original config file FIRST.
Thanks, great stuff!
You should take the “
" out of your config example
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
OK, thanks for letting me know. I didn’t know it was so bad. What do you suggest I use instead?
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?
Thanks Bjorn. This helped me a great deal!
Hey, thanks for the tip! Didn’t know that it was so easy to fix.
saved a lot of time.Thanx!
I always did this on PuTTY. But when I switched to using cygwin/mintty, the ssh connections would always timeout. Thanks for the tip.
You changed my life for ever. May the Unix force be with you forever and ever.
lol the WordPress comment, haha
And thank you so muchfor the timeout tip, I was going crazy.
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”.
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.
Elegant. Thank you!
Thanks that worked.
Worked for me, Thank you BJØRN!
Comments are closed.