SSH Timeouts with ClientAliveInterval and ClientAliveCountMax

Question

What I want to accomplish is to simply terminate inactive SSH sessions. Just because the user is logged in does not mean that the user is doing something. I need the SSH daemon to logout users after X seconds of inactivity.

Debian Bullseye as well as CentOS does not auto logout inactive SSH sessions. At least not within a reasonable time period. By reasonable, I mean less than 10 minutes.

Before posting this question, I’ve searched and read through serverfault.com similar issues but I could not find any post with the right answers.

After reading a bunch of articles, including Debian's man pages https://manpages.debian.org/stretch/openssh-server/sshd_config.5.en.html I implemented the two options related to ssh inactivity in /etc/ssh/sshd_config file as follows:

ClientAliveInterval 300
ClientAliveCountMax 1

The timeout value is calculated by multiplying ClientAliveInterval with ClientAliveCountMax.

timeout interval = ClientAliveInterval * ClientAliveCountMax

This setup works great on CentOS as i get the "Connection to x.x.x.x closed by remote host." but it does not work on Debian.

Am i misinterpreting the documentation? Could someone explain what I am doing wrong?

Thank you.

Answer 1

OpenSSH options ClientAliveInterval and ClientAliveCountMax are not used to disconnect inactive sessions. They are in fact preventing the connection from being closed, even on inactive sessions, as long as the client and the network link is alive.

This is an internal mechanism of ssh that send a null packet inside the established tunnel, and wait for an answer from the client.

In your case, you send one packet every 300 seconds, and disconnect after 1 answer missed.

While these options are helpful to detect and cleanup disconnected client sessions, they will not kill sessions of clients who are still connected, even if inactive. Unless their client doesn't answer the null packet.

AS suggested by @noah, to disconnect inactive clients, if you are using bash as shell you could set the TMOUT value in a system-wide default or per-user profile:

       TMOUT  If  set to a value greater than zero, TMOUT is treated as the default timeout for the read builtin.  The select command terminates if input does not arrive
              after TMOUT seconds when input is coming from a terminal.  In an interactive shell, the value is interpreted as the number of seconds to wait for a line of
              input after issuing the primary prompt.  Bash terminates after waiting for that number of seconds if a complete line of input does not arrive.

For example, adding the following line to `/etc/bashrc` will close bash sessions of inactive user after 5 minutes, but read the following warning before enabling this:

`export TMOUT=300`

Warning: as a daily user of shells, I often let some terminal open while multitasking. I would personally find this TMOUT mechanism very annoying if set to a low value (even the 10 minutes you mention would really annoy me).
I would NOT recommend it unless it's at least set to a very high value (at least 1hour).

My opinion is that OpenSSH options `ClientAliveInterval` and `ClientAliveCountMax` (or `ServerAliveInterval` and `ServerAliveCountMax`, set on the server-side) are enough to get rid of zombies/disconnected clients. When using them you are already guaranteed that an active session on the server does match an open terminal on a connected client. 
It's the user's choice to keep their terminal open, while I understand you want to close disconnected clients, I don't see the point of closing sessions from legitimate users.

Answer 2

Not sure of the reason for Debian's timeout to not work but there are other methods to force logout.

So the first that comes to mind is adding to the profiles.d (or sudoers) config to auto-logout the user (expands the timeout to the console and sudo su commands).

Steps to enable: https://ostechnix.com/auto-logout-inactive-users-period-time-linux/

Answer 3

Adding some clarifying comments here, based on my testing of the other answers with Ubuntu Server 22.04. With the sshd ClientAliveInterval and ClientAliveCountMax mechanism, at least in my trials with a different Ubuntu system, the ssh client silently responses to the null Client Alive messages. So, if you keep that client active, it will never get killed. You can see it at work, however, if you suspend the client: ~^Z, that is tilde followed with Control-Z, and wait for your multiplied number of ClientAliveInterval * ClientAliveCountMax seconds, the connection will be closed, which you can observe when you resume the client from suspend (e.g. fg). If you don't know about the tilde commands in ssh, type ~? to get help.

So, I think the ClientAlive mechanism is good for catching ssh clients that have hung, stopped or are suspended and non-responsive machines, broken networks and other major tragedies.

I have tested TMOUT (export readonly TMOUT=7200) and found that works in bash as expected. However, I am not sure if it takes effect if a user has a different shell selected. Maybe each shell has its own mechanism or maybe they all use the same mechanism (but seldom do things work out that easily!). Note, ShellCheck complains about "export readonly" and wants "declare -rx", but I don't think scripts in /etc/profile.d are run in bash, but rather /bin/sh, where "declare" is not available.