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
(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.)
(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!
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.
closing resolved bugs as of 8.6p1 release