Restrict SSH Logins with AllowUsers Without Locking Yourself Out

A valid SSH key or password does not guarantee that an account can log in. OpenSSH can apply an additional server-side filter: AllowUsers lists which accounts are eligible to connect.

That makes it useful for limiting remote access on a shared server—but a typo or incomplete list can lock out administrators and automation. Treat it as an access-control change, not just a line to add to a config file.

What AllowUsers does

AllowUsers is an sshd setting. It belongs in the active SSH server configuration, not your client-side ~/.ssh/config. The OpenSSH server configuration guide explains where settings may live and how included configuration files can affect what the daemon reads.

To allow only one account:

AllowUsers deploy

To allow several:

AllowUsers deploy admin monitoring

These names must be the accounts’ actual login names on the server. The directive does not create accounts, grant them shell access, or change how they authenticate. A listed user must still satisfy the server’s authentication and account policies.

Conversely, once an AllowUsers list is in effect, accounts not matching it are excluded from SSH login—even if their credentials are otherwise valid. Before applying a rule, account for every person, deployment process, and recovery login that needs access.

Limit access by source address

You can match a username together with the source host or address that the server sees:

AllowUsers deploy@192.0.2.10

Here, deploy is the account on the SSH server, and 192.0.2.10 is the client’s source address. It is not the destination server’s address.

OpenSSH also supports CIDR address patterns, for example:

AllowUsers deploy@192.0.2.0/24

This can be useful when connections should come from a particular network. Be sure the pattern reflects the address the server actually sees. NAT, a VPN, or a jump host can make that different from the address configured on your laptop. Hostname patterns also depend on name resolution, so confirm how names resolve in your environment before relying on them.

If you add source restrictions, test from the network you intend to allow. A username can be correct while its host pattern still fails to match.

Understand the other access rules

OpenSSH offers related directives:

• AllowUsers allows matching account names, optionally paired with a source pattern.
• AllowGroups allows users based on group membership.
• DenyUsers and DenyGroups explicitly deny matching users or groups.

If you combine allow rules, a user may need to satisfy more than one condition. Deny rules take precedence over allow rules. Check the behavior of the OpenSSH version on your server and review all relevant directives rather than assuming one matching allow rule overrides the rest.

Apply the change safely

A syntax check is useful, but it cannot tell you whether the right person will be allowed in. Use a staged process:

1. Keep your current SSH session open. If available, make sure you have console or other out-of-band access.
2. Confirm the current account, other administrators, automation accounts, and recovery accounts are covered.
3. Edit the active server configuration or an included file that the daemon actually reads.
4. Test the configuration before applying it:

   sudo sshd -t

No output normally means the syntax check passed. If the server uses a non-default config file, pass its path with the appropriate -f option.

1. Apply the change using the service procedure for that system. Service names and reload behavior vary; the SSH service reload and restart guide covers those differences.
2. Open a new terminal and test a fresh connection for each account and source network that should work. Keep the old session open until those tests succeed.

If a new login fails, the existing session may be your easiest way to fix the rule. A successful sshd -t only checks configuration syntax; it does not simulate authentication or confirm that a user-and-host pattern matches.

When a listed user still cannot connect

AllowUsers is only one gate. If a listed account is rejected, verify the exact server-side username and source address, and check whether another allow or deny directive applies. Also confirm the account is permitted to log in and can satisfy an enabled authentication method.

The practical rule is simple: list the accounts that genuinely need remote access, validate the configuration, and verify with a fresh connection before closing your existing session.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.