SSH timeouts as a result of inactivity can be quite irritating. This usually compels you to reinitiate the connection and start all over again.
Thankfully, you can easily increase the SSH timeout limit and keep your SSH session alive even after some inactivity. This happens when either the server or the client sends null packets to the other system to keep the session alive.
Related Read: How to Secure and Harden OpenSSH Server
Let’s now explore how you can increase the SSH connection timeout in Linux.
Increase SSH Connection Timeout
On the server, head over to the /etc/ssh/sshd_config configuration file.
$ sudo vi /etc/ssh/sshd_config
Scroll and locate the following parameters:
#ClientAliveInterval #ClientAliveCountMax
The ClientAliveInterval parameter specifies the time in seconds that the server will wait before sending a null packet to the client system to keep the connection alive.
On the other hand, the ClientAliveCountMax parameter defines the number of client alive messages which are sent without getting any messages from the client. If this limit is reached while the messages are being sent, the sshd daemon will drop the session, effectively terminating the ssh session.
The timeout value is given by the product of the above parameters i.e.
Timeout value = ClientAliveInterval * ClientAliveCountMax
For example, let’s say you have defined your parameters as shown:
ClientAliveInterval 1200 ClientAliveCountMax 3
The Timeout value will be 1200 seconds * 3 = 3600 seconds. This is an equivalent of 1 hour, which implies that your ssh session will remain alive for idle time of 1 hour without dropping.
Alternatively, you can achieve the same result by specifying the ClientAliveInterval parameter alone.
ClientAliveInterval 3600
Once done, reload the OpenSSH daemon for the changes to come into effect.
$ sudo systemctl reload sshd
Conclusion
As an SSH security measure, it’s always advisable not to set the SSH timeout value to a huge value. This is to prevent someone from walking by and hijacking your session when you are away for an extended period of time. And that’s it for this topic.
This “solution” to set an idle timeout seems quite common on the internet, but it’s not actually correct. I am looking for a way to get the ssh daemon to enforce an idle timeout for users, which it seems many others are also looking for. Unfortunately, this is not what ClientAliveInterval and ClientAliveMaxCount do.
If you set ClientAliveInterval to a non-zero value, the server will send ClientAlive messages over the encrypted channel if it doesn’t see traffic from the client for that many seconds. This allows the client to respond over the channel that it is still alive and allows the server to clean up sessions where either the network connection has been interrupted or the client has died without gracefully disconnecting.
So if you set the interval to 60 and the MaxCount to 5, then you have some clients unexpectedly die due to a power failure or become inaccessible due to a network outage, the session will be killed off on the server about 5 minutes later. What it won’t do is kill off the session if the user walks away from their terminal for more than 5 minutes. That’s the problem I’m really trying to solve.
So far, the best solution I can find for that is to set the TMOUT environment variable in bash, although this only works at the primary shell prompt. If you happen to walk away whilst editing a file in vi or something like that, you again have an effectively infinite idle timeout.
The one thing that you can use ClientAliveInterval to solve is if you have a firewall timing out your NAT session after an annoyingly short idle time. This was the initial problem I set out to solve. When working on 3 screens with 2 or 3 shell sessions open, I would often encounter the problem when working predominantly in one window, the other windows would freeze after about 30 minutes.
I’d then need to wait about 5 minutes for the client to finally time out and realize that the TCP connection was dead and exit. Setting ClientAliveInterval to a shorter value than the firewall’s timeout value solved that problem by forcing ClientAlive messages to be sent over the connection periodically if there was no other traffic and thereby keeping the connection alive on the firewall.
With my current ClientAlive {Interval=30,MaxCount=3} settings, my sessions would die after 90 seconds of inactivity if this article was correct. In actuality, they’ll happily stay open for days if I don’t manually end them. If this sounds similar to your problem, then you probably want to set ClientAliveInterval to a relatively short time, like 60 seconds, rather than 1200 or 5000 like the earlier commenters.
That will get rid of annoying short timeouts due to the network or similar idle timeouts outside of sshd and your shell, but it does create the new problem of user sessions that may never timeout when idle.
The TMOUT environment variable provides a partial solution, but still has holes. Ideally, I wish there was an option to have sshd enforce an idle timeout based on no console activity, either input or output but so far there doesn’t seem to be an option to get sshd to do that.
I tried to reload sshd but my terminal still times out. I’ve configured ClientAliveInterval 5000. Do you have any idea?
I did like but you said in the post, but my ssh connection disconnect after about 30 minutes with the below error :
client_loop: send disconnect: Broken pipe
It happened when I try to install along with automatade script and I have no control over my session to execute any command. because the script is progressing. i set “ClientAliveInterval 1200” and “ClientAliveCountMax 3” in sshd_config
At least in Ubuntu for OpenSSH, it looks like this “ClientAliveInterval” setting was a hack and no longer supported as a connection timeout setting according to this August 2020 post: https://askubuntu.com/a/1265510
Hi,
I am looking for a parameter that can handle the server timeout request for an SSH connection. In other words, if a user is trying to establish a connection with an SSH Server (which doesn’t exist), then how long can we keep the connection request alive, using that parameter.
Kindly suggest the same.
Regards
Good article, but I think the variable is ‘ClientAliveInterval’, not ‘ClientIntervalAlive’.
@Rich,
Thanks for notifying, corrected the variable in the article.