Using `Match User` in sshd_config to Force Key‑Only Access for Specific Users

Why Key‑Only for a Few Users Matters

Running an SSH service usually lets you try both password and key authentication. Most of the time key‑only is the safer bet, but you might want to enforce it only for a handful of high‑privilege accounts—developers, sysadmins, or anyone who needs to keep a tight grip on the machine. OpenSSH’s Match directive makes that a breeze without touching the global defaults.

Configuring Match User

Open the daemon configuration:

sudo nano /etc/ssh/sshd_config

Drop a block at the end of the file:

Match User alice,bob
    PasswordAuthentication no
    ChallengeResponseAuthentication no
    PubkeyAuthentication yes

Match User takes a comma‑separated list. Wildcards (*) work too, so Match User *admin* will catch any username containing “admin”.
The directives inside the block override the global values only for those users.
If you have PasswordAuthentication yes globally, the block above will turn it off for alice and bob while leaving it on for everyone else.

After editing, reload SSH:

sudo systemctl reload sshd

Example: Combining with `AllowUsers`

If you’re already whitelisting logins with AllowUsers, you can layer both:

AllowUsers alice bob charlie
Match User alice,bob
    PasswordAuthentication no

charlie keeps the password option, but alice and bob are forced to use keys.

Practical Tips

Situation	Recommendation	Reason
Enforce key‑only for an entire group	Use `Match Group` instead of `Match User`	Keeps the config tidy and scales when group membership changes
Need a temporary password for a user	Add a `Match User tempuser` block that re‑enables `PasswordAuthentication`	No need to touch the global setting
PAM password policies are in play	Keep `PasswordAuthentication no` inside the block, but leave PAM enabled for others	PAM still applies to non‑matched users

When you use Match, remember that order matters. The first matching block wins, so place specific user blocks before more generic ones.

Common Pitfalls

Missing PubkeyAuthentication yes – If you forget to enable it, the user will be locked out. The default is yes, but it’s safer to be explicit inside the block.
Overlapping blocks – Two Match User blocks that overlap can produce confusing results. Test with ssh -vvv to see which block applies.
Reload vs. restart – systemctl reload sshd preserves existing connections. If you need a clean restart (e.g., after changing ListenAddress), use systemctl restart sshd.
File permissions – sshd_config must be owned by root and mode 600. Otherwise, SSH will ignore the file for security reasons.

Testing the Change

From a non‑matched user:
```
ssh charlie@server
```
You should be prompted for a password.
From a matched user:
```
ssh alice@server
```
If you have a key in ~/.ssh/id_rsa.pub, the login should succeed without a password prompt. If you don’t, SSH will refuse the connection.
Verbose output:
```
ssh -vvv alice@server
```
Look for lines like debug1: Authentications that can continue: publickey. If you see password in the list, the block didn’t apply.

When to Use Match User

High‑privilege accounts – Developers or system admins who should never fall back to passwords.
Compliance – Some regulations require key‑only for specific roles.
Testing – Temporarily disable password auth for a user while you rotate keys.

If you later decide to revert, simply remove or comment out the block and reload SSH. The global PasswordAuthentication setting will take over again.

linux ssh hardening