Restrict which users can log in over SSH

The fix/etc/ssh/sshd_config

AllowGroups sshusers

Create the group and put the accounts that need SSH into it:

sudo groupadd -f sshusers
sudo usermod -aG sshusers youruser

Then reload the daemon:

sudo systemctl reload ssh     # Debian, Ubuntu
sudo systemctl reload sshd    # RHEL, Rocky, Alma, Fedora

Why it matters

By default, every account on the host with a valid shell and credentials can log in over SSH. That includes accounts created by packages, accounts left behind by a departed colleague, and service accounts that were never meant to be interactive.

An allow-list inverts the default. Instead of remembering to lock down every account that shouldn’t have SSH, you name the few that should, and everything else is denied — including accounts that don’t exist yet.

Which directive to use

AllowGroups is the one to reach for. It survives staff changes: adding or removing a person is a group membership change, not an sshd config edit and reload.

Use AllowUsers when you want per-host precision, and note it accepts a user@host pattern that restricts where a user may connect from:

AllowUsers deploy@10.0.0.0/8 youruser

The evaluation order catches people out

OpenSSH checks the four rules in a fixed order, and the first match wins:

1. DenyUsers
2. AllowUsers
3. DenyGroups
4. AllowGroups

Two consequences worth knowing:

• A deny always beats an allow, regardless of which line comes first in the file. Listing someone in both DenyUsers and AllowUsers denies them.
• If AllowUsers is set at all, anyone not listed is denied — even if they are in a group named by AllowGroups. Setting both is the usual way people lock themselves out: AllowUsers deploy plus AllowGroups sshusers does not mean “either”, it means “only deploy”.

Pick one directive and use it alone unless you have a specific reason not to.

Verify it worked

Check the effective rule against the running daemon:

sudo sshd -T | grep -iE '^(allow|deny)(users|groups)'

Expect only the rule you set:

allowgroups sshusers

Then confirm your own account actually matches it:

groups youruser

If sshusers isn’t in that output, you are about to be locked out.

Before you apply this

Group membership only applies to new logins. Your current session was authenticated before the group existed, so groups in your existing shell may not show sshusers yet — that is expected and is not proof of anything.

Verify from a second terminal, with your current session still open:

ssh youruser@host 'groups'

If that returns a list containing sshusers, the rule will match you and the change is safe. If the login is refused, your existing session is the only way back in — remove or fix the directive before closing it.

Related

• Require key-only SSH authentication — restrict who can try, then restrict how.
• Disable root login over SSH — the one account worth denying by name.