Bug 3056

Summary:	A non-idle session always be terminated when set ClientAliveCountMax to 0
Product:	Portable OpenSSH	Reporter:	abel.xie <chenxixie0422>
Component:	sshd	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED INVALID
Severity:	enhancement	CC:	dtucker
Priority:	P5
Version:	8.0p1
Hardware:	amd64
OS:	Linux

Description abel.xie 2019-08-14 08:45:29 AEST

The issue exists from version 7.6p1.
reproduce steps:
1) set sshd_config:
   ClientAliveInterval 60
   ClientAliveCountMax 0

2) user ssh login, then compile our project, the compile time will take more than 60 seconds:

   [abel@AbelCentOS75 ~/build/Cloud/Agent/linux]$make
   starting to compile...
   ...
   <a lot of output>
   ...
   Connection to localhost closed.
   ===> the session get closed unexpectly after 60 seconds.
   
I understand that with ClientAliveCountMax == 0 there will be no "client alive packet"sent and the client ssh session will be terminated
after ClientAliveInterval seconds of idle time. 

But in my use case, the client session keep receiving data from server side, is it still an "idle" session? the user experience is terrible.

after dig into it, I found the behavior change since 7.6p1 is from https://bugzilla.mindrot.org/show_bug.cgi?id=2756

before 7.6p1, if there are any incomming or outgoing traffic from ssh client side, sshd think the connection is not idle.

after 7.6p1, only if there are any incomming traffic from ssh client, sshd think it's not idle.

Also, for the reason why I set the ClientAliveCountMax to 0, it is recommended by "CIS CentOS Linux 7 Benchmark", you can get the content easily from here:
https://secscan.acron.pl/centos7/5/2/13

Comment 1 Darren Tucker 2019-08-14 09:53:03 AEST

(In reply to abel.xie from comment #0)
[...]
> But in my use case, the client session keep receiving data from
> server side, is it still an "idle" session? the user experience is
> terrible.

Well it's doing exactly what you asked it to, and it's consistent with what the documentation says it'll do.

> after dig into it, I found the behavior change since 7.6p1 is from
> https://bugzilla.mindrot.org/show_bug.cgi?id=2756
> 
> before 7.6p1, if there are any incomming or outgoing traffic from
> ssh client side, sshd think the connection is not idle.
> 
> after 7.6p1, only if there are any incomming traffic from ssh
> client, sshd think it's not idle.
> 
> Also, for the reason why I set the ClientAliveCountMax to 0, it is
> recommended by "CIS CentOS Linux 7 Benchmark", you can get the
> content easily from here:
> https://secscan.acron.pl/centos7/5/2/13

That's not really what ClientAlive is for,  you probably want something like bash's TMOUT.  ClientAlive is intended to detect clients that have dropped off the network.

With the previous behaviour, regular output would have it considered alive even if it wasn't and the traffic would likely end up buffered in the TCP socket buffer.  (BTW it'd also mean that you could leave a build unattended and someone could ctrl-C it and subvert your intended policy too.)

Comment 2 abel.xie 2019-08-16 08:21:15 AEST

(In reply to Darren Tucker from comment #1)
> (In reply to abel.xie from comment #0)
> [...]
> > But in my use case, the client session keep receiving data from
> > server side, is it still an "idle" session? the user experience is
> > terrible.
> 
> Well it's doing exactly what you asked it to, and it's consistent
> with what the documentation says it'll do.
> 
> > after dig into it, I found the behavior change since 7.6p1 is from
> > https://bugzilla.mindrot.org/show_bug.cgi?id=2756
> > 
> > before 7.6p1, if there are any incomming or outgoing traffic from
> > ssh client side, sshd think the connection is not idle.
> > 
> > after 7.6p1, only if there are any incomming traffic from ssh
> > client, sshd think it's not idle.
> > 
> > Also, for the reason why I set the ClientAliveCountMax to 0, it is
> > recommended by "CIS CentOS Linux 7 Benchmark", you can get the
> > content easily from here:
> > https://secscan.acron.pl/centos7/5/2/13
> 
> That's not really what ClientAlive is for,  you probably want
> something like bash's TMOUT.  ClientAlive is intended to detect
> clients that have dropped off the network.
> 
> With the previous behaviour, regular output would have it considered
> alive even if it wasn't and the traffic would likely end up buffered
> in the TCP socket buffer.  (BTW it'd also mean that you could leave
> a build unattended and someone could ctrl-C it and subvert your
> intended policy too.)

OK, Thanks for your explanation!

Comment 3 Darren Tucker 2019-08-16 08:34:30 AEST

BTW you shouldn't rely on ClientAliveInterval to disconnect your idle users as they could trivially defeat it by setting ServerAliveInterval in the client to a slightly lower value.

Comment 4 Damien Miller 2021-04-23 14:55:47 AEST

closing resolved bugs as of 8.6p1 release