Set SSH Client Alive Interval
Sets ClientAliveInterval 300 so sshd probes idle sessions every 300 seconds, enabling automatic disconnection of inactive logins.
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.
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
Terminating idle SSH sessions promptly reduces the window in which an unattended, logged-in terminal can be hijacked by someone with physical or network access. Combined with ClientAliveCountMax, ClientAliveInterval 300 causes the daemon to drop a session that has been idle for the configured time, enforcing a server-side inactivity timeout independent of client behavior.
What Pavois checks
Pavois reads the effective clientaliveinterval 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(/^clientaliveinterval\s+300$/i) }
endHow to verify it is applied
Run sudo sshd -T | grep -i clientaliveinterval. The expected output is clientaliveinterval 300.
Inspect & investigate
Timed-out disconnections 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 clientaliveinterval to 300 in a managed drop-in, validates it with sshd -t -f %{path}, then notifies a reload of the ssh service so the idle timeout takes effect without dropping live sessions. Pair it with ssh-set-keepalive (ClientAliveCountMax 0) for a hard 300-second idle limit.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | clientaliveinterval |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | 300 |
| verify | sshd -t -f %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without an idle timeout, an unattended SSH session can stay open indefinitely and be hijacked. Setting ClientAliveInterval 300 is broadly safe. Precaution: long-running interactive jobs with no terminal output (compilations, REPLs, manual DB sessions) may be disconnected when idle, wrap them in tmux/screen, or nohup/systemd-run for unattended work. Note the timeout measures server→client liveness probes, so genuine traffic resets the timer. The reload preserves your current SSH session, so there is no lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.1.7, 8.2.8, 5.1.9 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.11, AC-12, AC-17(a), AC-2(5), CM-6(a), SC-10 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 8.2.8 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-255035, UBTU-24-600010 | direct | per OS STIG release | high |
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.