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.

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

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