Bug 2627 - Documentation update: semantic of ClientAliveCountMax 0 unclear
Summary: Documentation update: semantic of ClientAliveCountMax 0 unclear
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 7.3p1
Hardware: All All
: P5 trivial
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_8_2
  Show dependency treegraph
 
Reported: 2016-10-21 04:44 AEDT by Woody Weaver
Modified: 2022-06-22 18:57 AEST (History)
4 users (show)

See Also:


Attachments
ban ClientAliveCountMax=0 (465 bytes, patch)
2019-07-19 15:08 AEST, Damien Miller
dtucker: ok+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Woody Weaver 2016-10-21 04:44:56 AEDT
It seems to be reasonably well understood (e.g. https://lists.mindrot.org/pipermail/openssh-unix-dev/2013-November/031781.html) that setting ClientAliveCountMax to 0 can terminate an alive but idle session.  However, this is not clear, as demonstrated by that email.

It would be helpful to add something like

>With ClientAliveCountMax == 0 there will be no "client alive packet"
>sent and I will force a disconnection if there is no traffic within
>ClientAliveInterval secs.

to the section on ClientAliveCountMax or ClientAliveInterval.
Comment 1 Damien Miller 2019-07-19 15:08:30 AEST
Created attachment 3301 [details]
ban ClientAliveCountMax=0

Maybe we should just ban ClientAliveCountMax=0, or make it equivalent to ClientAliveInterval=0 in stopping checks
Comment 2 Damien Miller 2020-01-26 09:42:00 AEDT
I committed an alternate change: ClientAliveCountMax=0 will disable connection-killing entirely. This will be released in OpenSSH 8.2
Comment 3 Damien Miller 2021-03-04 09:52:18 AEDT
close bugs that were resolved in OpenSSH 8.5 release cycle
Comment 4 Vince Salvino 2021-10-24 05:47:03 AEDT
I just stumbled upon this bug after several hours of head-scratching as to why my sshd configuration quit working as expected after testing an upgrade to Debian 11 (which includes OpenSSH 8.4).

We are a hosting provider, and actually use ClientAliveCountMax=0 to forcibly disconnect clients if they have just been sitting there doing nothing (but technically maintaining an active connection). This is more common than you would think, as it also applies to the internal-sftp functionality. It is very common for users to simply leave their SFTP clients or SSH terminals open for days because they never close apps or never reboot their machines. There are hundreds of blog posts and articles written about this behavior as well.

The original behavior made sense, as it would send a probe at ClientAliveInterval (e.g. 10 minutes) of inactivity, and check for a response ClientAliveCountMax (e.g. 1) times. If it got a response, it would keep the connection alive until the next check. Therefore setting ClientAliveCountMax=0, means it would send a probe after 10 minutes of inactivity and immediately close the connection, regardless of the response.

Would it be possible to restore this functionality, with the proper documentation? Or would it make sense to add a new option, something like "ClientKillInterval" which would forcibly terminate the connection after the specified interval of time, if the client hasn't performed any activity.
Comment 5 James Dingwall 2022-06-22 18:57:31 AEST
As per comment#4 after an upgrade from Ubuntu 18.04 to Ubuntu 20.04 the ClientAlive* settings no longer functioned as expected.  My personal opinion is that the existing behaviour (disconnect with no probes) could have been clarified in the man page but actually changing behaviour that existing configurations depended on was not the correct decision.  It is also unclear what advantage the new behaviour of ClientAliveCountMax=0 brings, if you don't want the client connection to be killed then don't configure the parameters, the default ClientAliveInterval=0 already meant that these messages would not be sent.

Perhaps if you want a client alive message to be sent then ClientAliveCountMax=-1 could have indicated no disconnect.

cross reference: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1978816