How to disable password authentication on an SSH server

An SSH server can accept several authentication methods. Setting its PasswordAuthentication option to no disables the password method, while KbdInteractiveAuthentication controls keyboard-interactive authentication separately.

On Debian and Ubuntu, OpenSSH loads local configuration snippets before most settings in the main server configuration. An early global snippet can disable password authentication for all accounts, but a matching Match rule can override that policy.

A tested SSH key and an open administrator session protect against losing access when authentication changes. Removing the password method still permits other allowed methods, including PAM-backed password or one-time-code prompts through keyboard-interactive authentication when it is enabled.

1. Keep one administrator session open on the server before changing SSH authentication.

   A bad authentication change can block new remote logins. The existing session or a separate console provides a recovery path until the final login test passes.

2. Confirm key login works from the client without a password prompt.

   $ ssh user@host.example.net whoami
   user

   Here, user and host.example.net stand for your server account and hostname. A prompt for the private key's passphrase is fine, but a prompt for the account password means key access needs fixing before the server changes.
   Related: How to configure passwordless SSH login

3. Open a new drop-in file in an editor from the administrator session.

   $ sudoedit /etc/ssh/sshd_config.d/00-disable-password-authentication.conf

   sshd keeps the first value it reads, and the 00- prefix sorts ahead of typical package or cloud snippets. Debian and Ubuntu load this directory from an Include line near the top of /etc/ssh/sshd_config. On a server without that line, the setting goes in that file instead, above any existing PasswordAuthentication line or Match block.

4. Disable the password method by saving PasswordAuthentication no in the drop-in file.

   /etc/ssh/sshd_config.d/00-disable-password-authentication.conf

   PasswordAuthentication no

   This sets a server-wide policy. A per-user Match User policy controls that user's authentication methods and does not deny the account all SSH access.
   Related: How to allow or deny SSH access for users and groups

   PasswordAuthentication no leaves keyboard-interactive authentication unchanged. If PAM-backed password or OTP prompts must also be removed, that setting needs separate attention.
   Related: How to disable keyboard-interactive authentication in SSH

5. Test the sshd configuration syntax.

   $ sudo sshd -t

   No output means the daemon parsed the configuration and checked its host keys successfully. A reported error must be fixed before reloading.
   Related: How to test SSH server configuration

6. Verify the effective password-authentication setting.

   $ sudo sshd -T
   ##### snipped #####
   pubkeyauthentication yes
   ##### snipped #####
   passwordauthentication no
   kbdinteractiveauthentication no
   ##### snipped #####

   The passwordauthentication no line shows the new setting is in effect. If it reports yes, an earlier setting needs correction before reloading. If kbdinteractiveauthentication reports yes, password-like prompts may remain. This output shows the global policy, so a Match block in the configuration can still turn passwords back on for the logins it matches.

7. Reload the SSH service.

   $ sudo systemctl reload ssh

   Reloading applies the change to new connections while preserving the administrator session. Debian and Ubuntu use the ssh service unit; other distributions may use a different unit name.
   Related: How to manage the SSH server service with systemctl

8. Confirm the server refuses a login without the key.

   $ ssh -o PubkeyAuthentication=no user@host.example.net
   user@host.example.net: Permission denied (publickey).

   The refusal is expected, and the methods in parentheses no longer include password. A password prompt here means a Match block or keyboard-interactive authentication still allows a password for this account.

9. Confirm key login still works from the client.

   $ ssh user@host.example.net whoami
   user

   If this fails, the administrator session remains the recovery path for correcting the configuration. The session should remain open until the refused login and this key login both give the expected results.