Require key-only SSH authentication

The fix/etc/ssh/sshd_config

PasswordAuthentication no
KbdInteractiveAuthentication no

Then reload the daemon:

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

Why it matters

A password is a secret short enough for a human to remember, which is also short enough to guess at scale. SSH keys are not guessable in any practical sense, and they remove the entire category of brute-force and credential-stuffing attacks that make up most of the noise against a public host.

The gotcha: two directives, not one

PasswordAuthentication no on its own is frequently not enough, and this is the single most common way a host that looks locked down still accepts passwords.

OpenSSH has a second path to password authentication: keyboard-interactive, which delegates to PAM. If KbdInteractiveAuthentication is left on while PAM is configured for passwords, the daemon will still prompt for and accept a password — even though PasswordAuthentication is no. Setting both is what actually closes the door.

On older configs the same directive appears under its former name, ChallengeResponseAuthentication. If you see that in your config, it is the same setting; set it to no as well.

Verify it worked

Check both directives against the running daemon:

sudo sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication'

Expect both to be off:

passwordauthentication no
kbdinteractiveauthentication no

Then prove it from the outside. This should be rejected without ever offering a password prompt:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@host

Expect Permission denied (publickey). If you get a password prompt, one of the two directives is not live.

Before you apply this

Your key must work before you turn passwords off. Confirm it from a second terminal, with your current session still open:

ssh -o PasswordAuthentication=no youruser@host

If that logs you in, your key is in place and this change is safe. If it asks for a password or refuses, your key is not installed correctly — fix that first, or this directive will lock you out of the host.

Copy a key up with ssh-copy-id youruser@host while password auth is still enabled.

Related

• Disable root login over SSH — apply this next.