Ensure SSH LoginGraceTime is configured
Limit the SSH authentication grace period to 60 seconds via LoginGraceTime.
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
LoginGraceTime caps the time a connection may stay open without authenticating. Leaving it at the default (120 seconds) keeps half-open, unauthenticated sockets alive longer, which lets an attacker hold many concurrent slots and slowly run brute-force or password-guessing attempts. Setting it to 60 shrinks that window, frees the daemon faster and reduces exposure to login-stage denial-of-service.
What Pavois checks
Pavois asserts that the effective value reported by sshd -T is logingracetime 60. Reading the live daemon output (rather than /etc/ssh/sshd_config) captures the value that actually applies after every Include and every drop-in under /etc/ssh/sshd_config.d/ has been merged, a file-based scan can miss an override and report a false pass or false fail.
describe command('sshd -T') do
its('stdout') { should match(/^logingracetime\s+60$/i) }
endHow to verify it is applied
Run sshd -T | grep -i logingracetime. Expected output:
logingracetime 60
Inspect & investigate
Connection setup and timeouts are visible in /var/log/auth.log (Debian/Ubuntu) or via journalctl -u ssh / journalctl -u sshd (RHEL family). Sessions that exceed the grace time are dropped with a Timeout before authentication message.
Remediation
Pavois's harden plan sets the sshd_setting resource for directive logingracetime to 60, validates the candidate config with sshd -t before activating it, then notifies a reload of the ssh service so the new value takes effect. Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | logingracetime |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | 60 |
| verify | sshd -t -f %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A short grace period is low-risk for interactive users but can interrupt slow authentication flows, for example smart-card/PIN prompts, multi-factor challenges or high-latency links, if a user takes longer than 60 seconds to authenticate. Before applying, confirm your MFA/keyboard-interactive flows complete well under the limit, keep a second root session open in case of misconfiguration, and rely on the built-in sshd -t validation so a syntax error never breaks the listener.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 5.1.13, 5.1.14, 5.1.15 | direct | per OS, see the benchmark table | high |
| PCI DSS | 2.2.6 | supporting | 4.0.1 | medium |
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.