Limit SSH logins to the users and groups that need them

Description

The OpenSSH server options AllowGroups, AllowUsers, DenyGroups and DenyUsers restrict which accounts may log in, whatever credentials they hold. A typical setup allows one group, for example AllowGroups ssh-users, and adds the people who administer or use the host to it.

Rationale

Many accounts exist on a system for services, applications or past projects. An allow list makes SSH access a deliberate decision per account, so that a key or password left on an account that should not log in remotely is useless to an attacker.

Impact

Accounts outside the list, including automation accounts, cannot log in anymore. The list must be kept up to date with arrivals and departures. The right list depends on the host, which is why there is no automatic fix.

Applies when

Detected: when: OpenSSH server is installed A scanner reports the control not applicable when one is false.

Audit

Run sshd -T | grep -E '^(allowusers|allowgroups|denyusers|denygroups) '. At least one of these options must be set, and the accounts or groups it allows must match the list of people and tools that need SSH access to this host.

Remediation

1. Create a group (groupadd ssh-users) and add the accounts that need SSH access (usermod -aG ssh-users <account>), starting with your own.
2. Add AllowGroups ssh-users to /etc/ssh/sshd_config.d/00-cirsec.conf.
3. Check with sshd -t, run systemctl reload ssh, and test a new connection before closing the current one.

Rollback

Remove the AllowGroups line and run systemctl reload ssh.

References

• sshd_config(5), Debian manual pages Debian, vendor-doc, accessed 2026-10-18
• NIST IR 7966 - Security of Interactive and Automated Access Management Using Secure Shell (SSH) NIST, guide, accessed 2026-10-18

Mappings

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Threats mitigated

People and lifecycle