[Bug 3056] A non-idle session always be terminated when set ClientAliveCountMax to 0

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3056

--- Comment #2 from abel.xie <chenxixie0422 at gmail.com> ---
(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!

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.