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.

I believe this is fixed in this upstream PR. Can you please verify?
https://github.com/ComplianceAsCode/content/pull/6030

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.

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?

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

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.

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.

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.

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?

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