How to disable SSH password login on Ubuntu — without locking yourself out

Keys proven first, then a one-file drop-in named to sort before cloud-init's, because in sshd_config the first value wins. The sshd -t check and the second-session test that make it safe.

The short answer

Prove key login works first, then drop one file into /etc/ssh/sshd_config.d/ and reload. This is the drop-in:

# /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

sshd -t && systemctl try-reload-or-restart ssh

The 00- prefix is load-bearing: in sshd’s config the first value for a keyword wins, and cloud images ship their own drop-ins that would otherwise get there first. Keep your current session open and test from a second terminal before you call it done.

Why keys-only is worth it

A public server’s SSH port collects password-guessing attempts around the clock. That background noise is automated and universal. With PasswordAuthentication no, every one of those guesses dies before a password is even considered; with keys, the secret that opens the box never crosses the network at all. The often-missed sibling setting is KbdInteractiveAuthentication no: keyboard-interactive is a challenge-response flow that, via PAM, usually just asks for the same password through a different door. Disabling only PasswordAuthentication and leaving keyboard-interactive on is the classic half-done hardening mistake. PermitRootLogin prohibit-password keeps root reachable by key while refusing root passwords specifically.

Step zero: don’t lock yourself out

The only dangerous part of this change is doing it before key access is proven, and a script that hardens first and checks later locks its author out. Confirm you can log in with your key today, forcing the question with

ssh -o PreferredAuthentications=publickey \
    you@server

Keep your working session open while you change config, and know where your provider’s web console lives: it’s the out-of-band recovery door if SSH ever refuses you.

Why a drop-in file, and why the name matters

Modern Ubuntu’s /etc/ssh/sshd_config begins with Include /etc/ssh/sshd_config.d/*.conf, and sshd applies the first occurrence of each keyword it reads. Later mentions lose. Two consequences. First, editing the main file is fragile (package upgrades prompt about your changes; a drop-in survives untouched). Second, and the part that silently defeats many guides: cloud images already have opinions in that directory. Ubuntu cloud instances typically carry a cloud-init-written drop-in (commonly 50-cloud-init.conf, often containing PasswordAuthentication yes), so a file named after it alphabetically never gets a vote. Run ls /etc/ssh/sshd_config.d/ before choosing your filename; a 00- prefix sorts ahead of anything an image vendor shipped. Then sshd -t validates the whole config before anything restarts. Make it a habit, because sshd that fails to parse config fails closed.

The reload wrinkle on Ubuntu 24.04

If systemctl reload ssh answers “ssh.service is not active, cannot reload,” nothing is wrong with your change: Ubuntu runs sshd socket-activated now, so the service may simply not be running between connections. That’s why the command above is try-reload-or-restart: it’s a no-op when inactive, and your hardened config applies on the next connection anyway. The full story of socket-activated SSH is its own guide. It has killed more than one provisioning script mid-run.

Verify like you mean it

From a second terminal, confirm keys still work, then confirm passwords are actually refused:

# should log in via key:
ssh you@server

# should fail fast, with no prompt:
ssh -o PubkeyAuthentication=no \
    -o PreferredAuthentications=password \
    you@server

The second command should come back with “Permission denied” without ever prompting for a password. A password prompt means some earlier config file still says yes, so go read the drop-in directory again. Belt-and-braces extras that cost nothing: lock the account’s password outright (passwd -l username), and audit what else the server exposes while you’re in the neighborhood with a quick open-ports check.