RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1873547 - Rules "Set SSH Idle TImeout Interval" and "Set SSH Client Alive Max Count" are fundamentally broken.
Summary: Rules "Set SSH Idle TImeout Interval" and "Set SSH Client Alive Max Count" ar...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: scap-security-guide
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: 8.0
Assignee: Vojtech Polasek
QA Contact: Matus Marhefka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-28 15:12 UTC by Martin Poole
Modified: 2024-06-13 23:00 UTC (History)
10 users (show)

Fixed In Version: scap-security-guide-0.1.53-2.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-18 15:54:31 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Martin Poole 2020-08-28 15:12:38 UTC
Description of problem:

The two rules used in many of the profiles

   "Set SSH Idle TImeout Interval"

and its associated

   "Set SSH Client Alive Max Count"

have a fundamental problem.

openssh does not have any mechanism to provide an idle session tiemout.

This includes all historical versions, all versions we ship and all upstream versions.

The descriptions that come with rules state

    "Set SSH Idle Timeout Interval"

        SSH allows administrators to set an idle timeout interval. After this interval has passed,
        the idle user will be automatically logged out. To set an idle timeout interval, edit the
        following line in /etc/ssh/sshd_config as follows: ClientAliveInterval 600
        The timeout interval is given in seconds. To have a timeout of e.g. 10 minutes,
        set interval to 600. If a shorter timeout has already been set for the login shell,
        that value will preempt any SSH setting made here. Keep in mind that some processes
        may stop SSH from correctly detecting that the user is idle.

    "Set SSH Client Alive Max Count"

        To ensure the SSH idle timeout occurs precisely when the ClientAliveInterval is set,
        edit /etc/ssh/sshd_config as follows: ClientAliveCountMax 0


Almost everything stated is wrong. Quite where this "information" came from is unclear.

What the ssh protocol does have is the ability to monitor the TCP connection to ensure the remote endpoint is still there. This is achieved via the server parameters ClientAliveInterval/ClientAliveCountMax and corresponding client ServerAliveInterval/ServerAliveCountMax parameters as documented in the man pages for ssh_config and sshd_config.

This protocol serves two purposes. It provides in-band data for a TCP connection in case there are firewalls or other intermediate devices that require traffic (over and above the presence of the TCP-level flag TCP_KEEPALIVE) to maintain state. The second purpose provides early termination of TCP connections whose connection state has either been discarded en-route or terminated due to end-point system crash and which would only then terminate after TCP connection timeouts (~2hr 20mins at default values).

Neither of these involves any determination of a user being idle.





Version-Release number of selected component (if applicable):

    scap-security-guide-0.1.48-7.el8.noarch

also

    scap-security-guide-0.1.46-11.el7.noarch
    scap-security-guide-0.1.28-4.el6.noarch


Quite what can be done about these rules I don't know. openssh simply does not have the functionality to provide idle timeout.

Comment 1 Matěj Týč 2020-09-09 14:58:35 UTC
Thank you for your report.
Those rules are extremely old, so it's difficult do determine how they got into the project. We have a trace of it back in 2011 in https://github.com/ComplianceAsCode/content/commit/3393d5af2d5e80d086a7394d8a564bf494b0da64, but that may not even be the first appearence.

The most likely explanation would be that the description of those configuration options was misunderstood, and nobody noticed that it up until today.
Therefore, we will re-evaluate implications of that configuration option, and either rewrite the description, or we will remove those rules if we conclude that the option is not related to security.

Comment 3 Vojtech Polasek 2020-10-02 13:58:45 UTC
I believe this is fixed in this upstream PR. Can you please verify?
https://github.com/ComplianceAsCode/content/pull/6030

Comment 4 Martin Poole 2020-10-02 14:34:42 UTC
No, I'm afraid the changes make no difference.

The test is still garbage.

Either

1. the intent is that implied by the test name "sshd_set_idle_timeout", ie sshd has an idle timeout to be verified

   In which case the entire sshd_set_idle_timeout test along with checking of of the ClientAliveInterval/ClientAliveCountMax values needs to be removed because openssh does not have this capability at all.
   Or possible just remove the ClientAliveInterval/ClientAliveCountMax checks and substitute a hard fail.

2. there is some other intent

   In which case the entire sshd_set_idle_timeout test along with checking of of the ClientAliveInterval/ClientAliveCountMax values needs to be removed and the correct rule needs to be rescoped and rebuilt from the ground up.

Comment 8 Vojtech Polasek 2020-10-08 17:45:54 UTC
Hm, I did some testing. If I configure
ClientAliveInterval 10
ClientAliveCountMax 0
Then the session disconnects after 10 seconds of being idle... that's what the rule actually says... So I am a bit confused. From the previous conversation I would guess that it should not work. Is there any case in which this would not work as it did for me?

Comment 11 Matěj Týč 2020-11-05 16:03:11 UTC
This subject has been extensively discussed with subject matter experts. It turned out that the rule involves two configuration options. As a result, the check has been updated to assert that both are set correctly, and limitations of this approach have been added to the rule description.

Fixed by https://github.com/ComplianceAsCode/content/pull/6293

Comment 18 Eric Negaard 2021-04-12 18:22:58 UTC
I agree with the original reporter, Martin, that the ClientAliveInterval and ClientAliveCountMax functionality is not and never has been meant to be an idle timeout mechanism for SSH and that any recommendations for using it as such is fundamentally broken.

It is true as Vojtech notes in comment #8 that in the very simple case of a session being completely idle for ClientAliveCountMax seconds that the idle session is disconnected.

The openssh ClientAlive code only counts input from the client as activity, however lack of input is not the only parameter that determines whether a connection is idle or not. With the settings used by Vojtech the session will also be dropped if there is constant output from the server side of the connection. Try for example redoing the test with ClientAliveCountMax=0 and ClientAliveInterval=10, but run "while sleep 1 ; do date ; done" and see that the session also gets disconnected in that case.

Add to that that there is currently a bug (see https://bugzilla.redhat.com/show_bug.cgi?id=1686065) that causes sessions that do have valid input activity to get prematurely disconnected if a RekeyLimit timeout is also specified, and the result is a system with very unstable connectivity and unexpected behavior.

Finally, note that in upstream openssh 8.2p1 and later, the ClientAlive timeouts are completely disabled when either ClientAliveInterval or ClientAliveCountMax are zero, so anyone implementing the current SCAP recommendations on an openssh 8.2p1 based system will not achieve the intended results in any circumstances.

Given all of the above, I believe that the recommendations for implementing an SSH idle timeout be completely removed since they are apparently based on an incorrect understanding of what the ClientAliveInterval and ClientAliveCountMax parameters do.

Comment 19 Steve Grubb 2021-04-12 18:50:54 UTC
Hello Eric, there are security requirements to drop idle sessions from the server's point of view. How else can that be met? This is the same reason that financial institutions close your login if you have not typed or clicked on anything in a site defined time interval. That very same web server that closes client https connections also has to do that for admin ssh connections. The SCAP content is not doing this because they think it's a good idea. They are doing it to comply with regulations imposed on the site operators. The text in the description for ClientAliveInterval is nearly identical to what the regulations ask for. If there is a better way of addressing this, I'm sure that can be incorporated instead. So far, no one has proposed a better way. Taking this out of openssh 8.2p1 and later without replacing it with something better helps no one.

Comment 20 Eric Negaard 2021-04-12 19:12:52 UTC
Hi Steve,

I completely understand the desire to drop idle sessions, but the parameters in question here do not disconnect idle sessions. They implement at best a one-way idle check, but using the financial institution example I'm pretty sure that if a was displaying a large csv file with say 120 lines at the rate of one line per second, that it wouldn't just drop the connection after 60 lines (60 seconds) even though there were 60 more lines to send - just because the user is watching the lines appear on the screen one at a time and waiting for it to finish.

And maybe you misunderstood the point about openssh 8.2p1. The functionality discussed here is already disabled in openssh 8.2p1, and 8.3p1, 8.4p1 and 8.5p1.

See https://github.com/openssh/openssh-portable/blob/V_8_2_P1/serverloop.c line #187:

    	if (options.client_alive_count_max > 0 &&

The client is only disconnected on entry to the client_alive_check function if ClientAliveCountMax is greater than zero. If ClientAliveCountMax is zero as is required to implement this so-called "SSH idle timeout" feature, the connection is no longer dropped.

Comment 21 Peter Vreman 2021-04-29 08:40:00 UTC
We also have the need to forcefully close from server side idle client connections in the context of SFTP server functionality.
In theory not able to terminate idle SFTP connections can lead to DoS attack on the SFTP service.

Is this Dos attack issue not seen from upstream?

Comment 23 errata-xmlrpc 2021-05-18 15:54:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (scap-security-guide bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1886


Note You need to log in before you can comment on or make changes to this bug.