openssh bugs - Nov 2021 - [Bug 3362] New: [RFE] Implement a mechanism to disconnect idle users

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

            Bug ID: 3362
           Summary: [RFE] Implement a mechanism to disconnect idle users
           Product: Portable OpenSSH
           Version: 8.8p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: ggasparb at redhat.com

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

--- Comment #1 from ggasparb at redhat.com ---
Related to: https://bugzilla.mindrot.org/show_bug.cgi?id=1338

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
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?

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

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

--- Comment #3 from ggasparb at redhat.com ---
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.

-- 
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.

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

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
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

-- 
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.

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

josh at honorablemenschen.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |josh at honorablemenschen.com

--- Comment #5 from josh at honorablemenschen.com ---
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.

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
since openssh-9.2 we have ChannelTimeout and UnusedConnectionTimeout to
deal with these cases

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

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

--- Comment #7 from josh at honorablemenschen.com ---
Unfortunately, this doesn't really fix the issue.  Because it requires
you to a) know which channels your users are using, and more
importantly b) which channels your users are NOT using, and adjust your
settings on the fly to match.  Because since each channel has its own
timeout, you can't just say, "disconnect after the user has done
nothing anywhere for 15 minutes".  For example, let's say a user logs
in with X forwarding enabled, then opens an SSH session to another
server, and starts an X program on that server in the background.  If
you're watching for inactivity on all channels, then if the shell
channel goes inactive (because they're working in the X window), the
connection gets terminated while they are most definitely NOT idle
(easy to test - set ChannelTimeout *=5m; ssh to that server, then from
there to another server; start an xterm window, in it run a while loop
that outputs to the screen.  After the 5 minutes of inactivity in the
shell, the entire SSH gets killed.  The same is not true if the while
loop is run directly in the SSH session shell).  The same is
potentially true in other situations as well.  While this mechanism may
ultimately hold value, the fact that each channel is monitored for
timeout separately and there's not a way to say, "Monitor for
inactivity across all channels with a single timeout value that gets
updated if there's activity on any channel" severely limits the
usefulness of this new method.  Because of this limitation, this is not
a viable solution to the requested functionality.

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