[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear
https://bugzilla.mindrot.org/show_bug.cgi?id=2627 --- Comment #8 from Christopher Maynard --- (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. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear
https://bugzilla.mindrot.org/show_bug.cgi?id=2627 --- Comment #7 from Damien Miller --- 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. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear
https://bugzilla.mindrot.org/show_bug.cgi?id=2627 Christopher Maynard changed: What|Removed |Added CC||christopher.mayn...@igt.com --- Comment #6 from Christopher Maynard --- (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. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear
https://bugzilla.mindrot.org/show_bug.cgi?id=2627 James Dingwall changed: What|Removed |Added CC||james.dingw...@ncr.com --- Comment #5 from James Dingwall --- 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. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear
https://bugzilla.mindrot.org/show_bug.cgi?id=2627 Damien Miller changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Damien Miller --- 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. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear
https://bugzilla.mindrot.org/show_bug.cgi?id=2627 Damien Miller changed: What|Removed |Added Blocks||3079 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Damien Miller --- 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. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear
https://bugzilla.mindrot.org/show_bug.cgi?id=2627 Darren Tucker changed: What|Removed |Added Attachment #3301|ok?(dtuc...@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. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear
https://bugzilla.mindrot.org/show_bug.cgi?id=2627 Damien Miller changed: What|Removed |Added CC||d...@mindrot.org, ||dtuc...@dtucker.net Attachment #3301||ok?(dtuc...@dtucker.net) Flags|| --- Comment #1 from Damien Miller --- 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. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
