Set SSH Daemon LogLevel to VERBOSE
Set sshd LogLevel to VERBOSE so login activity and authenticating key fingerprints are logged.
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
VERBOSE logging records SSH login and logout activity and the key fingerprint used to authenticate. That fingerprint is decisive for incident response and forensics: it lets you attribute a session to a specific key, spot use of an unexpected or revoked key, and discount sessions that merely disconnected. DEBUG is not a substitute, it drowns security signal in protocol noise, and anything below INFO loses the audit trail entirely, leaving account misuse undetectable.
What Pavois checks
Pavois asserts that the effective sshd -T output reports exactly loglevel verbose. Querying the live 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 downgrades the level and would report a false pass.
describe command('sshd -T') do
its('stdout') { should match(/^loglevel\s+verbose$/i) }
endHow to verify it is applied
Run sshd -T | grep -i loglevel. Expected output:
loglevel VERBOSE
Inspect & investigate
Authentication events land in /var/log/auth.log (Debian/Ubuntu) or journalctl -u ssh / journalctl -u sshd (RHEL family). At VERBOSE each accepted login records the key fingerprint, e.g. Accepted publickey for user ... key: SHA256:....
Remediation
Pavois's harden plan sets the sshd_setting resource for directive loglevel to verbose, validates the candidate config with sshd -t, then notifies a reload of the ssh service so logging takes effect immediately. 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 does not affect connectivity, so there is no lockout risk. Expect higher log volume than INFO; verify that log rotation and disk space are sized for it. Do not use DEBUG in production, it can leak sensitive protocol internals and degrades the usefulness of the audit trail.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 5.1.15, 5.1.16 | direct | per OS, see the benchmark table | high |
| NIST | AC-17(1), AC-17(a), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| 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.