WardtermSSH client
EN
Download

How to disable password login for SSH

First confirm a key login works and keep a session open. Then create /etc/ssh/sshd_config.d/00-no-passwords.conf with PasswordAuthentication no and KbdInteractiveAuthentication no, run sudo sshd -t, reload the service, and check the result with sudo sshd -T. Editing sshd_config alone often has no effect, because an earlier drop-in file wins.

Updated . Run on OpenSSH 10.0 on Debian 13 with a client on macOS, including the drop-in override, the password login through keyboard-interactive, and sshd stopping on a broken file.

Before you change anything

Prove that a key works. This command only tries keys, so a password cannot hide a problem:

ssh -o PreferredAuthentications=publickey user@server

No key yet? Generate an Ed25519 SSH key and put it on the server first.

Check that this account can use sudo, and keep one logged-in session open until the last step. Existing sessions carried on through a reload in our test, so that session is your way back if the new settings lock you out. If your provider has a web console, find it now.

See what is in effect today

sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication|usepam|permitrootlogin) '

sshd -T prints the values sshd really uses after reading all its files. Trust this, not what you read in sshd_config.

Why editing sshd_config often does nothing

For most settings, sshd uses the first value it finds. On current Debian and Ubuntu, the Include /etc/ssh/sshd_config.d/*.conf line is near the top of sshd_config, so drop-in files are read first, in name order. Check yours:

grep -n Include /etc/ssh/sshd_config
ls /etc/ssh/sshd_config.d/

Cloud images often ship a file like 50-cloud-init.conf containing PasswordAuthentication yes. We tested that case: with that file in place, setting PasswordAuthentication no in sshd_config left sshd -T still showing yes.

A file whose name sorts first wins over all of them, which is why the name below starts with 00. If there is no Include line, as on servers older than OpenSSH 8.2 or with a customized file, put the settings in sshd_config itself, above any Match block, and remove any earlier lines that set them.

Create the drop-in file

sudo tee /etc/ssh/sshd_config.d/00-no-passwords.conf >/dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

KbdInteractiveAuthentication needs to be off too. With only PasswordAuthentication no and this setting on, our test server still accepted the account password, because PAM asks for it through keyboard-interactive. Before OpenSSH 8.7 the option was called ChallengeResponseAuthentication, and the old name still works as an alias.

UsePAM can stay yes. PAM also handles account checks and session setup, and with the two lines above it no longer offers a password prompt. Some distributions warn against turning it off, so leave it alone.

PermitRootLogin prohibit-password lets root log in only with a key. Use no if nobody should log in as root. Up to OpenSSH 10.0, sshd -T shows prohibit-password under its older name, without-password.

Test the file, then reload

sudo sshd -t
sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication) '

sshd -t prints nothing when the configuration is valid. Do not skip it: we sent the reload signal to an sshd with an invalid line in a drop-in file, and it exited, leaving nothing listening for new connections.

sudo systemctl reload ssh     # Debian, Ubuntu
sudo systemctl reload sshd    # RHEL, Fedora, Arch

Prefer reload to restart. A reload only asks the running sshd to read its configuration again, and our open session survived it. On Debian 13 the service file also runs sshd -t before sending the signal, so a broken file stops the reload there, but do not count on every distribution doing this.

Confirm from another terminal

Leave the open session alone, and try a password login from your own machine:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive user@server

The result should be Permission denied (publickey). with no password prompt. Then check that your key still gets in with a new connection. Only then close the old session.

If a password prompt still appears

  • Run sudo sshd -T again. If it shows yes, some other file sets it first: search with sudo grep -ri passwordauthentication /etc/ssh/.
  • Look for a Match block. It can turn passwords back on for some users or addresses, and plain sshd -T does not show that. Pass the connection details to evaluate it: 
    sudo sshd -T -C user=user,host=example.com,addr=203.0.113.10 | grep -i ^passwordauthentication
  • Check you are reaching this server and this port, and not a different machine behind the same name.
  • A prompt for a key passphrase is not a password prompt. It comes from your own machine and unlocks your key.

Questions

Is PasswordAuthentication no enough?

Not always. With KbdInteractiveAuthentication on, PAM can still ask for the password through keyboard-interactive. Turn both off.

Why does sshd_config say no but passwords still work?

A drop-in file in /etc/ssh/sshd_config.d is read first and wins. Check the value in use with sudo sshd -T.

Should I set UsePAM no?

No. PAM also handles account checks and sessions. With the two settings off, it no longer asks for a password.

Sources

More in Keys and login

All guides