Password authentication on SSH is the single setting that turns a leaked or guessed credential into a shell. Turning it off is five lines of config; doing it across a fleet without locking yourself out is the part that needs an order. This is that order, including the check that proves keys work before you disable the fallback, why AuthenticationMethods beats PasswordAuthentication alone, and how to leave one deliberate way back in.
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.
Or read how we handle it in Security & Compliance.
Related Articles
How to Handle Secrets in CI Without Leaking Them Into Logs
The safest credential in your pipeline is the one that does not exist between jobs. OpenID Connect lets a workflow authenticate directly to a cloud provider and receive a token that expires on its own, which removes the stored key entirely. Masking is the backstop for everything left over, and it is worth knowing exactly where it stops working, because it relies on finding an exact match for the value. This guide covers the short-lived credential setup, the limits of redaction, and what to actually do in the ten minutes after a secret reaches a log.
SecurityA cPanel Account With Email Access Can Reach Root, and Every Supported Version Is Affected
CVE-2026-67401 lets an authenticated cPanel account holder with mail privileges create arbitrary files and run code as root. cPanel lists all supported versions as affected and has shipped patched builds. The precondition is an ordinary customer account, which on a hosting platform anyone can buy.
SecurityHow to Read a CVE and Decide in Ten Minutes If It Touches You
An alarming headline and a severity score are not a decision, and the score cannot become one because the part of it that would describe your environment is the part nobody filled in. This is the ten minute route from a CVE number to a defensible answer, covering what the scoring specification actually says, why your installed version number may be lying about whether you are patched, and which public sources report real exploitation rather than the possibility of it.