openssh bugs - Oct 2016 - [Bug 2627] New: Documentation update: semantic of ClientAliveCountMax 0 unclear

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

            Bug ID: 2627
           Summary: Documentation update: semantic of ClientAliveCountMax
                    0 unclear
           Product: Portable OpenSSH
           Version: 7.3p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: trivial
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: woody.weaver at comcast.net

It seems to be reasonably well understood (e.g.
https://lists.mindrot.org/pipermail/openssh-unix-dev/2013-November/031781.html)
that setting ClientAliveCountMax to 0 can terminate an alive but idle
session.  However, this is not clear, as demonstrated by that email.

It would be helpful to add something like
>With ClientAliveCountMax == 0 there will be no "client alive
packet"
>sent and I will force a disconnection if there is no traffic within
>ClientAliveInterval secs.
to the section on ClientAliveCountMax or ClientAliveInterval.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org,
                   |                            |dtucker at dtucker.net
   Attachment #3301|                            |ok?(dtucker at dtucker.net)
              Flags|                            |

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Created attachment 3301
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3301&action=edit
ban ClientAliveCountMax=0

Maybe we should just ban ClientAliveCountMax=0, or make it equivalent
to ClientAliveInterval=0 in stopping checks

-- 
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=2627

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3301|ok?(dtucker at dtucker.net)    |ok+
              Flags|                            |

-- 
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=2627

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
I committed an alternate change: ClientAliveCountMax=0 will disable
connection-killing entirely. This will be released in OpenSSH 8.2


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3079
[Bug 3079] Tracking bug for 8.2 release
-- 
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=2627

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
close bugs that were resolved in OpenSSH 8.5 release cycle

-- 
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=2627

James Dingwall <james.dingwall at ncr.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |james.dingwall at ncr.com

--- Comment #5 from James Dingwall <james.dingwall at ncr.com> ---
As per comment#4 after an upgrade from Ubuntu 18.04 to Ubuntu 20.04 the
ClientAlive* settings no longer functioned as expected.  My personal
opinion is that the existing behaviour (disconnect with no probes)
could have been clarified in the man page but actually changing
behaviour that existing configurations depended on was not the correct
decision.  It is also unclear what advantage the new behaviour of
ClientAliveCountMax=0 brings, if you don't want the client connection
to be killed then don't configure the parameters, the default
ClientAliveInterval=0 already meant that these messages would not be
sent.

Perhaps if you want a client alive message to be sent then
ClientAliveCountMax=-1 could have indicated no disconnect.

cross reference:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1978816

-- 
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=2627

Christopher Maynard <christopher.maynard at igt.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |christopher.maynard at igt.com

--- Comment #6 from Christopher Maynard <christopher.maynard at igt.com>
---
(In reply to Damien Miller from comment #2)
> I committed an alternate change: ClientAliveCountMax=0 will disable
> connection-killing entirely. This will be released in OpenSSH 8.2
I think this was the absolute wrong thing to do.  This bug report was
opened to clarify the documentation about the exact behavior of setting
ClientAliveCountMax=0, not to change the behavior of it, and in doing
so completely break backward-compatibility in the process.

Our organization has just been bitten by this change where previously
idle SSH sessions would automatically time out and terminate after the
configured value of ClientAliveInterval, as expected.  Now this no
longer happens and idle sessions remain active indefinitely.  I fail to
see any possible positive use case for SSH sessions to remain active
indefinitely, and in fact, the new behavior is now perceived as an
increased security risk.

How many idle SSH sessions are unknowingly remaining active now, I
wonder?  In today's security conscious world, this change in behavior
is simply terrible and quite frankly inexcusable.

For the benefit of all users, please revert this change.

-- 
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=2627

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
If you were relying on an accidental, unreliable and undocumented
behaviour for security then you always destined to have a bad time. 

ClientAliveCountMax=0 *never* worked as a reliable inactivity timeout -
ServerAliveInterval or a number of other things that caused non-session
traffic could keep a connection alive indefinitely. A security control
that appears to work but silently fails under common conditions is
worse than useless.

We've since added explicit, documented and supported inactivity timeout
mechanisms (ChannelTimeout and UnusedConnectionTimeout), so the
previous accidental behaviour of ClientAliveCountMax won't be coming
back.

-- 
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=2627

--- Comment #8 from Christopher Maynard <christopher.maynard at igt.com>
---
(In reply to Damien Miller from comment #7)
> If you were relying on an accidental, unreliable and undocumented
> behaviour for security then you always destined to have a bad time. 
The behavior was tested with the options we specified and it worked
exactly as desired.  You chose to make a change that broke that
behavior, seemingly without any regard to its implications, judging by
the lack of any discussions surrounding the change.  Yes, users are
going to have a bad time when developers behave in such ways.
> ClientAliveCountMax=0 *never* worked as a reliable inactivity
> timeout - ServerAliveInterval or a number of other things that
> caused non-session traffic could keep a connection alive
> indefinitely. A security control that appears to work but silently
> fails under common conditions is worse than useless.
You do realize that users control all their own options, don't you? 
And that users generally do test those options to ensure they work as
desired?  I would say a break in functionality that 100% ensures
failure is worse than useless, and borderline malicious.
> We've since added explicit, documented and supported inactivity
> timeout mechanisms (ChannelTimeout and UnusedConnectionTimeout), so
> the previous accidental behaviour of ClientAliveCountMax won't be
> coming back.
And when were those options added?  According to
https://www.openssh.com/releasenotes.html, they were added in OpenSSH
9.2.  So what about those of us using older versions such as OpenSSH
8.2 
 The fact that ClientAliveCountMax=0 behavior changed in OpenSSH 8.2
without regard to backward-compatibility and without those 2 new
options being added in conjunction with that behavioral change in order
to provide a mechanism by which the same behavior could be realized as
before just goes to show how poorly and sloppily the change was made
with barely a thought to its implication.  I sincerely hope that
considerably more thought is given to future changes that break
backward-compatibility than what has been demonstrated here.

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