Enable PAM
Enables the PAM stack for SSH logins by setting UsePAM yes in sshd.
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
With UsePAM yes, sshd runs the system's PAM account and session stacks during login. This is what enforces account-level controls, access by IP, time-of-day or membership (pam_access), account expiry and lockout (pam_faillock/pam_tally2), resource limits (pam_limits), and consistent session setup (pam_env, pam_systemd). Without it, SSH bypasses these centralized controls entirely, leaving disabled or expired accounts able to log in and breaking lockout policies.
What Pavois checks
Pavois reads the effective usepam 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/, sshd -T reflects exactly what the running daemon enforces.
describe command('sshd -T') do
its('stdout') { should match(/^usepam\s+yes$/i) }
endHow to verify it is applied
Run sudo sshd -T | grep -i usepam. The expected output is usepam yes.
Inspect & investigate
PAM decisions for SSH (account denied, session opened/closed, faillock) appear in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family); follow with journalctl -u ssh -f (or -u sshd). Look for pam_unix, pam_faillock and pam_access messages.
Remediation
pavois harden apply sets the sshd_setting directive usepam to yes in a managed drop-in, validates it with sshd -t -f %{path}, then notifies a reload of the ssh service so the PAM stack is engaged without dropping live sessions.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | usepam |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | yes |
| verify | sshd -t -f %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Running SSH with UsePAM no silently bypasses account expiry, lockout and access-control policies, a serious security gap. Enabling it is generally safe and required by most distributions. Precaution: a broken PAM configuration (e.g. a misordered or missing module in /etc/pam.d/sshd) can cause every login to fail once UsePAM yes is active, so verify the PAM stack is sane first and keep a second session or console open when applying. The reload preserves your current SSH session, limiting lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 5.1.22, 5.1.24 | direct | per OS, see the benchmark table | high |
| PCI DSS | 2.2.6 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-255065, UBTU-24-500050 | 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.