vps

Disable Password Login — SSH Key Authentication Only

The final security step for SSH: disabling password authentication entirely so only key holders can connect. How to do it safely, why it matters, and what to do the one or two times you lock yourself out anyway.

Published
· 4 min read · Steven Doan ·
sshsecurityrocky-linuxvpsauthenticationbeginners
Terminal showing sshd_config with PasswordAuthentication no highlighted

This is the step that makes everything before it click into place.

You changed the SSH port — the bots targeting port 22 disappear. You set up Fail2ban — repeated attempts from the same IP get blocked. But as long as password authentication is enabled, there is still something worth attacking. Disable it, and the entire category of brute-force attack becomes irrelevant.

Why This Is the Last Security Step

The order matters. Disabling passwords before having SSH keys configured locks you out permanently — no password fallback means no access. That’s why this comes last in Part 3, after:

  • SSH key created and copied to the server (Part 2.5)
  • Keys confirmed working on your machines (Part 2.6)
  • Multiple machines set up with their own keys (good practice)

If any of that isn’t done, complete it before this article.

Before You Start — Confirm Your Key Works

Open a new terminal window and test SSH key authentication:

ssh -p 2222 youruser@your-server-ip

You should connect without being asked for a password. If you see a password prompt, your key is not set up correctly — stop here and fix that first.

Step 1 — Edit sshd_config

Keep your existing SSH session open. In that same session:

sudo nano /etc/ssh/sshd_config

Find PasswordAuthentication. It may be commented out:

#PasswordAuthentication yes

Uncomment it and set to no:

PasswordAuthentication no

While you’re in the file, also verify these are set correctly:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

These should already be the defaults — confirm they’re not commented out or set to no.

Save and exit: Ctrl+O, Enter, Ctrl+X.

nano editor showing sshd_config with PasswordAuthentication no highlighted and PubkeyAuthentication yes visible
Two things to confirm: PasswordAuthentication no, and PubkeyAuthentication yes. Both must be set.

Step 2 — Test Config and Restart

Check for syntax errors before restarting:

sudo sshd -t

No output means no errors. Then restart:

sudo systemctl restart sshd

Step 3 — Test Immediately

From the new terminal window you opened earlier, try connecting again:

ssh -p 2222 youruser@your-server-ip

Still connects without a password prompt — good. Password authentication is disabled and key auth is working.

Now test that passwords are actually rejected. Try connecting with the -o PasswordAuthentication=yes flag to force a password attempt:

ssh -p 2222 -o PasswordAuthentication=yes -o PubkeyAuthentication=no youruser@your-server-ip

You should see:

youruser@your-server-ip: Permission denied (publickey).

Permission denied (publickey) confirms passwords are disabled — the server is only accepting key authentication.

What the Auth Log Looks Like After This

Before disabling passwords:

Failed password for root from 185.220.101.45 port 54321 ssh2
Failed password for admin from 193.32.127.11 port 23456 ssh2
Failed password for ubuntu from 45.142.212.10 port 34567 ssh2

After disabling passwords (with Fail2ban running):

Disconnected from invalid user root 185.220.101.45 port 54321 [preauth]

The bots still scan. They find the port (if they port-scan your server). They attempt to connect. But password authentication is gone — they get disconnected at the preauth stage, before any credentials are even checked. Fail2ban sees the repeated attempts and bans the IP. The auth log becomes much quieter.

If You Get Locked Out

This happened to me once or twice — usually because a key wasn’t properly copied to a new machine before connecting from it.

Use the Vultr web console:

Log into your Vultr dashboard → click your server → click the Console tab.

From the browser console, temporarily re-enable password auth:

sudo nano /etc/ssh/sshd_config
# Change: PasswordAuthentication no
# To:     PasswordAuthentication yes
sudo systemctl restart sshd

Then set a temporary password for your user:

sudo passwd youruser

Now SSH in normally with the password, add your key properly to ~/.ssh/authorized_keys, confirm it works, then go back and disable passwords again.

Part 3 Complete — Security Checklist

You’ve completed all four steps in Part 3. Run through this checklist:

# 1. Confirm SSH is on custom port (not 22)
sudo ss -tlnp | grep sshd

# 2. Confirm firewalld has correct ports open
sudo firewall-cmd --list-all

# 3. Confirm Fail2ban is running and watching SSH
sudo fail2ban-client status sshd

# 4. Confirm password authentication is disabled
sudo grep "PasswordAuthentication" /etc/ssh/sshd_config

# 5. Confirm you can still SSH in with your key
# (test from local machine)

All five checks pass — your server is locked down. Every brute-force attack against SSH from this point forward hits a closed port or a key-only barrier. The background noise in your auth log becomes irrelevant.

Part 4 starts the actual stack installation: Nginx, PHP-FPM, MariaDB. The server is now ready for it.

Frequently Asked Questions

What happens if I disable password login before setting up SSH keys?
You lose SSH access entirely. There is no password fallback, and key authentication won't work if you haven't set it up. Always confirm your SSH key works from a separate terminal before disabling passwords — this is why the two-window approach matters.
Is SSH key authentication actually that much more secure than a strong password?
Yes, significantly. A strong password can still be brute-forced given enough time and attempts. An SSH key pair is mathematically infeasible to crack — the key length makes dictionary and brute-force attacks impractical. Once passwords are disabled, those attack vectors disappear entirely.
What if I lose my SSH key and can't connect?
Use the Vultr web console — accessible from the Vultr dashboard under your server's Console tab. From there you can temporarily re-enable password authentication in sshd_config, set a password for your user, connect via SSH to add a new key, then disable passwords again.
Do I need to do this if I already have Fail2ban running?
Yes. Fail2ban limits brute force attempts but doesn't eliminate the attack surface. Password authentication being available means there's still something to brute-force. Disabling it entirely removes the possibility — Fail2ban then becomes a secondary layer rather than the primary defense.