Disable SSH password authentication safely on Ubuntu

Preconditions matter more than the edit

Do not start until a new key-authenticated session works for your intended administrator and sudo access is usable. Keep that session open. If your organisation relies on PAM-based MFA or keyboard-interactive authentication, review that design first: disabling it blindly can remove a legitimate access route.

Inspect the effective settings

sudo sshd -T | sed -n '/^passwordauthentication /p; /^kbdinteractiveauthentication /p; /^pubkeyauthentication /p; /^permitrootlogin /p'

Inspect /etc/ssh/sshd_config and its included files. OpenSSH generally uses the first obtained value for a directive, so adding a later file does not guarantee an override. Match blocks can produce different settings for different users or source addresses.

Make one reviewed change

Use a sudo editor on the active configuration location. For a basic key-only design that does not use keyboard-interactive MFA, the intended directives are:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

These are configuration lines, not shell commands. Disabling root login is appropriate only after a standard administrative account has been verified. Do not overwrite the entire existing SSH configuration.

Validate before reloading

sudo sshd -t
sudo sshd -T

No output from the syntax test normally indicates success. Inspect the effective directives again. If Match rules exist, use sshd -T with an appropriate -C user/host/addr context to evaluate the connection you intend to permit.

On Ubuntu using the ssh service, reload only after validation:

sudo systemctl reload ssh

If your installation uses another unit or socket-activated configuration, follow its documented service process. Authentication changes are different from changing the listening port.

Prove both sides of the policy

Open a new key-authenticated connection and verify sudo. Then perform a controlled password-only connection attempt to your own server and confirm it is rejected. Keep the original session until both tests pass.

Common failures

A cloud-init drop-in, earlier Include or Match block can explain why the setting differs from the line you edited. Do not keep adding contradictory files. Fix the actual precedence problem and repeat validation. If access fails, use the retained session or console to restore the prior reviewed configuration.