Many security policies have a security requirement related to disconnect idle users from remote connections. So far, this requirement has been fulfilled by misusing the ClientAliveInterval and ClientAliveCountMax options by setting ClientAliveCountMax to zero. Newer version of openssh dropped completely this undocumented behavior and currently there is no other alternative to fulfill the requirement. This RFE is to add such mechanism where idle users are automatically disconnected from the remote connection after a certain predefined time.
Related to: https://bugzilla.mindrot.org/show_bug.cgi?id=1338
So, ClientAliveInterval=0 was never intended as an idle mechanism and never really worked as one. E.g. a client that has ServerAliveInterval set would never times out. AFAIK most shells support the $TMOUT variable to configure an idle timeout and putting "SetEnv TIMOUT=600" in sshd_config seems to work fine for the shells that I have at hand (bash and ksh). Is anything more inside sshd actually required?
I'm aware of this option, the problem is that it can be easily bypassed and does not work for every shell. https://stackoverflow.com/questions/17397069/unset-readonly-variable-in-bash/54705440#54705440 Unless ssh config prevents somehow this from being overriden, I don't think we can use it for shells that support TMOUT.
If someone's going to go to the trouble of ptracing the bash process then I'm pretty sure they could run a background process that prints a character every $TMOUT-1 second
This is another call to either restore the previous functionality (which, I will point out, is "documented" as a solution to disconnecting idle SSH connections all over the web, including posts dated well after the change in OpenSSH - not your problem, yet it does point out a widespread usage of said functionality). While i understand the call to use the TMOUT shell variable, that ONLY works when the SSH session in question is ALSO the shell in question. SSHing into one system where the TMOUT variable is set and then SSHing from there into another system completely eliminates the first shell's timeout functionality, as it never returns to a shell prompt until the SSH session exits. And when the timeout needs to be implemented on the first server, but not the second (e.g., a bastion gateway SSH server used to provide access to internal servers that don't/shouldn't have timeout on shells), it essentially eliminates the ability to timeout idle SSH sessions on that first server. I understand that the ClientAliveInterval and ClientAliveCountMax were not originally intended to provide a timeout functionality, and that logically ClientAliveCountMax=0 should disable the option, but in today's network environment there needs to be a reasonable way to force idle SSH connections to close at the SSH server level. Can I suggest that perhaps setting ClientAliveCountMax=-1 would be a reasonable way to tell sshd that if it waits ClientAliveInterval without any data packets that it should close the connection immediately? That could then be documented as explicitly being the way to disconnect idle sessions - set ClientAliveInterval=<timeout> and ClientAliveCountMax=-1 to automatically disconnect after <timeout> with no data.