Score:0

SSH Timeouts with ClientAliveInterval and ClientAliveCountMax

bw flag

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.

Score:0
in flag

I don't think the ClientAliveInterval and ClientAliveCountMax are helpfull to achieve your goal.

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.

Score:0
pk flag

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.

Score:0
ve flag

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/

puma avatar
bw flag
Thank you @noah-h for your reply. Although i can implement other methods, i hope someone can shed some light on the problem.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.