How to Kill Password SSH Across a Fleet, Once

Password SSH is the setting that converts a guessed, reused or leaked credential straight into a shell on your server. Every internet-facing host gets a constant background of login attempts against root, admin, ubuntu and a dictionary of the rest. With passwords enabled, that background noise is a lottery someone eventually wins.

Turning it off is a handful of lines. Doing it on forty machines without locking yourself out is a sequence, and the sequence is what this is about.

The order that does not lock you out

Never start by disabling passwords. Start by proving keys work.

1. Put the key on every host, while passwords still work.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@server1.example.com

Or across a fleet, if you already have Ansible:

ansible all -i inventory.ini -m authorized_key   -a "user=deploy state=present key='{{ lookup('file', '~/.ssh/id_ed25519.pub') }}'"   --ask-pass

2. Prove the key works, on every single host, before changing anything.

ansible all -i inventory.ini -m ping

If a host does not answer here, it will not answer after you disable passwords either. Fix it now, while you still have the fallback.

3. Only then change the config.

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

Modern distributions read /etc/ssh/sshd_config.d/*.conf, which is a better place than editing the main file, because a package upgrade will not fight you over it. Check that your sshd_config actually has the Include line; if it does not, edit the main file instead.

KbdInteractiveAuthentication matters. On many systems, turning off PasswordAuthentication alone still leaves a password prompt available through PAM keyboard-interactive. People disable one, test, see a prompt, and conclude the change did not apply.

4. Validate the config before you restart.

sshd -t && systemctl reload ssh

sshd -t parses the configuration and exits non-zero on a syntax error. Running it first is the difference between a reload and an outage.

5. Keep the session you have open, and test in a second one.

Open a new terminal and connect. If it fails, you still have the first session to undo the change. Closing your only session before testing is how this goes wrong.

Check what is actually in effect

Configuration files lie, because of includes, match blocks and the order of the first-wins rules. Ask the daemon instead:

sshd -T | grep -Ei 'passwordauthentication|kbdinteractive|permitrootlogin|pubkeyauthentication'

sshd -T prints the effective configuration after all includes are resolved. This is the only answer worth trusting, and it is the one to run across the fleet afterwards as proof.

Leave one deliberate way back in

Disabling passwords means a lost key is a lost server. Decide in advance which door stays open.

On a cloud provider, that is the serial or emergency console. On Hetzner, a rescue system. On bare metal, IPMI or physical access. Whichever it is, test that you can actually reach it before you need it, because discovering that your console access was never configured is a bad thing to learn at midnight.

A second, separate key held by a second person is the other common answer, and a good one.

Two more settings worth the same trip

While you are in the file, both of these cost nothing:

AllowUsers deploy admin
MaxAuthTries 3

AllowUsers means an attacker who somehow obtains a key for an unexpected account still gets nothing. MaxAuthTries cuts the number of attempts per connection.

If you want a second factor rather than a fallback, AuthenticationMethods publickey,keyboard-interactive requires both a key and a TOTP prompt, in that order. That is a real improvement over a key alone for administrative access, and it is worth the setup only if you will actually keep the TOTP secrets somewhere recoverable.

What this does not fix

Removing password SSH removes one entire class of attack. It does not help if the key itself is unprotected on a laptop, committed to a repository, or shared between six people and never rotated. Passphrase the private key, keep it in an agent, and give each person their own.

Fleet-wide hardening, done once and then kept true as machines come and go, is part of our security and compliance work and our server management engagements.