← All rules
SOCLE-CLD-SSH-022// SSHmediumeffective runtime

Set SSH Client Alive Count Max

Sets ClientAliveCountMax 0 so a session is dropped as soon as the first ClientAliveInterval elapses with no response.

Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 4 standards

Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.

A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.

Why this rule matters

ClientAliveCountMax controls how many unanswered keepalive probes sshd tolerates before closing a session. Setting it to 0 means the session is terminated immediately when an idle period of ClientAliveInterval passes, guaranteeing the idle timeout is honored without grace and minimizing the window in which an unattended session can be hijacked. It is the companion of ssh-set-idle-timeout; together they enforce a strict server-side inactivity disconnect.

What Pavois checks

Pavois reads the effective clientalivecountmax value from sshd -T, the daemon's resolved configuration. A scan of /etc/ssh/sshd_config could miss a value set in an Included drop-in under /etc/ssh/sshd_config.d/ or a Match block, sshd -T reflects exactly what the running daemon enforces.

describe command('sshd -T') do
  its('stdout') { should match(/^clientalivecountmax\s+[1-3]$/i) }
end

How to verify it is applied

Run sudo sshd -T | grep -i clientalivecountmax. The expected output is clientalivecountmax 0.

Inspect & investigate

Idle disconnections triggered by this setting are logged by sshd (e.g. Timeout, client not responding / Connection closed) in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family); follow with journalctl -u ssh -f (or -u sshd).

Remediation

pavois harden apply sets the sshd_setting directive clientalivecountmax to 0 in a managed drop-in, validates it with sshd -t -f %{path}, then notifies a reload of the ssh service so the strict timeout takes effect without dropping live sessions. It is only effective together with a non-zero ClientAliveInterval (see ssh-set-idle-timeout).

Pavois applies this with its own harden engine, the plan below, not a shell script:

directiveclientalivecountmax
notifyaction: reload, service: ssh.service
resourcesshd_setting
value1
verifysshd -t -f %{path}
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Leaving ClientAliveCountMax at its default (3) gives idle sessions extra grace before disconnect; setting it to 0 makes the timeout strict. Precaution: with a strict timeout, sessions on flaky or high-latency networks may be dropped if a single keepalive probe is missed during a brief outage, for unstable links consider client-side ServerAliveInterval and run long jobs under tmux/screen. Ensure ClientAliveInterval is set to a reasonable value (e.g. 300) so 0 does not produce an unexpectedly aggressive disconnect. The reload preserves your current SSH session, so there is no lockout risk.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS5.1.7, 8.2.8, 5.1.9directper OS, see the benchmark tablehigh
NIST3.1.11, AC-12, AC-17(a), AC-2(5), CM-6(a), SC-10supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
PCI DSS8.2.8supporting4.0.1medium
DISA STIGUBTU-22-255030, UBTU-24-600000directper OS STIG releasehigh

Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.

Sources & references