PasswordAuthentication

What PasswordAuthentication controls and its default

According to the sshd_config manual, the directive specifies whether password authentication is allowed, and the default is yes. That means a freshly installed sshd with no override accepts passwords for any account that has one.

It covers only the SSH method named password. Two neighbouring settings matter. KbdInteractiveAuthentication (the current name; ChallengeResponseAuthentication is a deprecated alias) has the default yes in the portable manual. And UsePAM, when enabled, turns on PAM authentication through both keyboard-interactive and password authentication. The portable manual notes that PAM keyboard-interactive usually serves an equivalent role to password authentication, so you should disable either PasswordAuthentication or KbdInteractiveAuthentication. For a key-only server, disable both and keep PubkeyAuthentication yes.

The directive affects SSH only. Passwords still work for the console, su and, where configured, sudo.

A minimal safe configuration and how to test it

The risk is switching passwords off before a key works. Prove key login first, from a second terminal, with the current session still open:

ssh -o PreferredAuthentications=publickey -i ~/.ssh/id_ed25519 -l deploy your-server

Then edit /etc/ssh/sshd_config and validate:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

sudo sshd -t
sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '
sudo systemctl reload ssh     # sshd on some distributions
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password -l deploy your-server

The last command, run from a new terminal, must end in "Permission denied" without offering a password prompt. As the sshd(8) manual describes, -t checks the configuration and -T prints the effective values. If you need a second factor, set AuthenticationMethods instead, as shown in the SSH two-factor guide. Keep your provider console available in case the key turns out not to work.

Interactions and common mistakes

Per the manual, the first obtained value for a keyword is used. If an included file or an earlier line already says PasswordAuthentication yes, your no lower down does nothing, so verify with sshd -T. The directive is allowed inside Match blocks, which lets you make an exception for one address or user, though that exception reopens the brute-force target for that match, so use it sparingly and test with -C.

• With UsePAM yes and keyboard-interactive left enabled, PAM can still ask for a password even though PasswordAuthentication no is set.
• When password authentication is allowed, PermitEmptyPasswords (default no) controls whether accounts with empty passwords may log in.
• If a listed AuthenticationMethods entry needs password, that method must also be enabled.
• Accounts created for key-only use often have no password, so check how sudo will authenticate them before you rely on it.

The sshd_config entry explains the file order in detail.

Where it fits in SSH hardening

Disabling passwords is the highest-impact single change in sshd_config: a guessed or leaked password stops being enough to log in, and brute-force attacks against SSH lose their target. It does not make the log noise disappear, since bots still connect and fail, so keep fail2ban or firewall rate limits in place and cap guesses per connection with MaxAuthTries.

Combine it with PermitRootLogin set to no, an allow-list through AllowUsers, and protected keys; the principles are in the entry on key-based authentication. The complete rollout order is in our SSH hardening guide, with fail2ban setup for the second layer. Primary sources: the sshd_config manual and the portable sshd_config(5) page for UsePAM and KbdInteractiveAuthentication. Once passwords are off, the authorized_keys files decide who can log in, so review them regularly.

Related terms: sshd_config, Key-based authentication, Brute-force attack, MaxAuthTries, Two-factor authentication.