Set LogLevel to INFO
Ensure sshd logs at INFO level or higher so login and logout events are recorded.
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
SSH offers several logging verbosities. DEBUG is discouraged outside protocol troubleshooting: it floods the log with data that buries security-relevant events. At least INFO (or the stronger VERBOSE) records SSH login and logout activity, which is essential for incident response, being able to tell when a given user was active, and to discount sessions that simply disconnected, narrows an investigation. Without adequate logging, account misuse and intrusions go unnoticed and unattributable.
What Pavois checks
Pavois asserts that the effective sshd -T output reports loglevel info or loglevel verbose. Querying the running daemon reflects the value resolved after all Include directives and /etc/ssh/sshd_config.d/ drop-ins are merged, a file scan can miss a drop-in that silently lowers the level to QUIET or DEBUG.
describe command('sshd -T') do
its('stdout') { should match(/^loglevel\s+(info|verbose)$/i) }
endHow to verify it is applied
Run sshd -T | grep -i loglevel. Expected output (either is acceptable):
loglevel INFOloglevel VERBOSE
Inspect & investigate
Authentication events land in /var/log/auth.log (Debian/Ubuntu) or journalctl -u ssh / journalctl -u sshd (RHEL family). At INFO you see Accepted/Failed login lines and session open/close; VERBOSE additionally logs the key fingerprint used.
Remediation
Pavois's harden plan sets the sshd_setting resource for directive loglevel to verbose (which satisfies this INFO-or-better rule), validates the candidate config with sshd -t, then notifies a reload of the ssh service. Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | loglevel |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | verbose |
| verify | sshd -t -f %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Raising the log level has no effect on connectivity, so there is no lockout risk. The only consequence is higher log volume (especially with VERBOSE); ensure log rotation and disk space are sized accordingly, and avoid DEBUG, which can expose sensitive protocol details and is not appropriate for production.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.1.14 | direct | per OS, see the benchmark table | high |
| NIST | AC-17(a), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | 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.