Limit Users' SSH Access
Requires sshd to define an explicit access list, at least one of AllowUsers, AllowGroups, DenyUsers or DenyGroups, so only approved accounts can log in over SSH.
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
By default any local account with a valid password or key can log in over SSH, including service and legacy accounts that should never have remote shell access. Explicitly allow-listing the few accounts (or groups) that need SSH, or deny-listing those that must not, shrinks the remote attack surface and limits the blast radius of a leaked credential, enforcing least privilege at the network entry point.
What Pavois checks
Pavois reads the effective sshd configuration with sshd -T, which prints the fully resolved directives after parsing sshd_config, every Include (e.g. /etc/ssh/sshd_config.d/*.conf) and any Match defaults. A file-based scan of sshd_config alone would miss directives placed in drop-ins or matched blocks, producing a false negative; sshd -T reflects what the daemon actually enforces.
describe command('sshd -T 2>/dev/null | grep -qiE \'^(allowusers|allowgroups|denyusers|denygroups) .\' && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run sshd -T | grep -iE '^(allowusers|allowgroups|denyusers|denygroups) '. The expected output is at least one such line with a non-empty value, e.g. allowgroups ssh-users.
Inspect & investigate
SSH authentication and access decisions are logged in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL), and via journalctl -u ssh / journalctl -u sshd. A user blocked by these lists appears as User <name> ... not allowed because ... in those logs.
Remediation
No automated harden plan is defined, so this must be applied manually: add an AllowGroups/AllowUsers (or DenyGroups/DenyUsers) directive, ideally in a drop-in such as /etc/ssh/sshd_config.d/10-access.conf, listing the approved accounts or groups, validate with sshd -t, then reload with systemctl reload ssh.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # Decide the allowed users/groups, then add to /etc/ssh/sshd_config.d/ a drop-in, e.g.: # AllowGroups ssh-users # and: systemctl reload ssh |
|---|---|
| reason | which users/groups may SSH is SITE-SPECIFIC, pavois cannot guess it |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
This is the highest-risk SSH change for lockout: an AllowUsers/AllowGroups list that omits your own account will deny your next login, and sshd does not retroactively kill existing sessions. Always include your administrative account/group, validate the config with sshd -t, reload (do not stop) sshd, and confirm a new login in a second session before closing the first. Service accounts that legitimately use SSH (backups, CI) must be included too.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 5.1.4, 5.1.7, 5.1.6 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.12, AC-3, 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.