AllowUsers

What AllowUsers does and how patterns work

The sshd_config manual says that if AllowUsers is specified, login is allowed only for user names that match one of the patterns, and that by default login is allowed for all users. Entries are separated by spaces. Only names are valid: a numerical user ID is not recognized. Patterns follow the rules in ssh_config(5), where * matches any number of characters, ? exactly one, and a leading ! negates an entry, though a negated match never produces a positive result by itself.

The form USER@HOST checks the user name and the connecting host separately, so a user can be allowed only from certain origins. The manual adds that the host part may contain addresses in CIDR address/masklen format. The group counterparts are AllowGroups, which matches a primary or supplementary group name, and the deny forms DenyUsers and DenyGroups.

Repeating the keyword on several lines does not replace the earlier list. In the OpenSSH source, each line appends to it.

A minimal safe configuration and how to test it

The classic lockout is listing the wrong name, or forgetting your own. List every account that must log in over SSH, including automation, then verify from a second terminal while your current session stays open:

# /etc/ssh/sshd_config
AllowUsers admin deploy@192.0.2.0/24

sudo sshd -t
sudo sshd -T | grep -i '^allowusers '
sudo systemctl reload ssh     # sshd on some distributions

Here admin may connect from anywhere, while deploy only from that network. sshd -t checks the file, and sshd -T prints the effective configuration, optionally with -C to apply Match blocks, as the sshd(8) manual explains. Then try to log in as an account that is not listed. It must be refused, and the server log should show a line in the form "User NAME from ADDRESS not allowed because not listed in AllowUsers" (taken from the OpenSSH source). Finally, confirm that your own login and every service account still work before you close the old session. Keep the provider console as a way back.

Precedence, interactions and common mistakes

The manual states that AllowUsers is not consulted for users matched by DenyUsers, and likewise for the group pair. The source shows the full order of checks: DenyUsers, then AllowUsers, then DenyGroups, then AllowGroups. A login must pass every list that is configured. If you set both AllowUsers deploy and AllowGroups ssh-users, deploy must also belong to ssh-users.

• Once AllowUsers exists, root is refused unless listed, even with PermitRootLogin yes. The two checks are independent.
• Backup, deploy and monitoring accounts that use SSH must be in the list, or their jobs will start failing.
• A negated pattern on its own never matches, so use DenyUsers for exclusions rather than AllowUsers !name.
• Because lines append, an AllowUsers line in an included file widens or changes your list; check the result with sshd -T.
• The keyword is allowed inside Match blocks.

Where it fits in SSH hardening

An allow-list shrinks the attack surface: a stolen key or a guessed password for an account that is not listed is rejected before it helps anyone. It also stops a newly created system account, or one added by a package, from becoming an SSH entry point by accident. For teams, AllowGroups is often easier to maintain than a list of names, since adding someone becomes a group change rather than a config edit.

AllowUsers works best next to PasswordAuthentication set to no, PermitRootLogin set to no and narrow sudo rules, following least privilege. In larger setups, funnel logins through a bastion host and restrict by source network at the firewall too. The rollout order is in our SSH hardening guide, the privilege side in users, sudo and least privilege, and the network side in the Linux firewall guide. Primary sources: the sshd_config manual and the OpenSSH auth.c source.

Related terms: sshd_config, PermitRootLogin, Least privilege, Bastion host, authorized_keys.