https://bugzilla.mindrot.org/show_bug.cgi?id=3362
j...@honorablemenschen.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |j...@honorablemenschen.com
--- Comment #5 from j...@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
