How to Disable SSH Password Login on a VPS (And Make It Actually Stick)

A default VPS accepts password logins on port 22, and that's exactly what automated bots are looking for. Within a short window of a new server going online, it's typically already being probed — scripted login attempts trying common usernames and password combinations, over and over, indefinitely. Switching to SSH keys and disabling password authentication entirely removes this attack surface: there's no password to guess because there isn't one to try.

This is one of the two highest-impact things you can do on a fresh VPS (the other is not running everything as root). It takes about five minutes — but there's a specific, commonly-missed gotcha on cloud VPS images that causes the change to silently not work, which we'll cover below.

Step 1: Set up an SSH key (before you touch the server config)

Don't disable password login until a key is already working — do it in the wrong order and you can lock yourself out entirely.

On your local machine (not the VPS):

ssh-keygen -t ed25519 -C "your-email@example.com"

Accept the default file location, and set a passphrase if you want an extra layer of protection on the key itself. Ed25519 is the modern default — smaller and faster than RSA with equivalent or better security; use ssh-keygen -t rsa -b 4096 instead only if you're connecting to something old enough not to support it.

Copy the public key to your server:

ssh-copy-id username@your-server-ip

If ssh-copy-id isn't available (some Windows setups), copy it manually:

cat ~/.ssh/id_ed25519.pub | ssh username@your-server-ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Step 2: Confirm the key works — in a new terminal, without closing your current session

Open a second terminal window and try logging in:

ssh username@your-server-ip

If you connect without being prompted for a password, the key is working. Keep your original session open until you've confirmed this — it's your safety net if anything goes wrong in the next step.

Step 3: Disable password authentication

On the VPS, edit the SSH daemon config:

sudo nano /etc/ssh/sshd_config

Find and set these three lines (uncomment them if they start with #):

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no matters as much as the password setting — if root can still log in directly, disabling passwords for other users doesn't fully close the door. Log in as your regular user and use sudo instead.

Step 4: The gotcha almost every guide skips

On Ubuntu cloud images (DigitalOcean, Hetzner, AWS, and most others), cloud-init — the tool that provisions your VPS on first boot — often drops its own config file at /etc/ssh/sshd_config.d/50-cloud-init.conf, and files in that directory are loaded after the main config and can silently override it. If that file still says PasswordAuthentication yes, your edit in Step 3 does nothing, and you won't find out until you assume you're protected.

Check for it:

cat /etc/ssh/sshd_config.d/*.conf 2>/dev/null | grep -i passwordauth

If it shows PasswordAuthentication yes, edit that file directly (or delete it, if nothing else in it matters to you) and set it to no as well. This one file is the reason so many people are confident they've disabled password login and haven't.

Step 5: Apply the change and verify

sudo systemctl restart ssh

Note the service name is ssh on current Ubuntu releases, not sshd — using the wrong name will fail silently on some setups with an "unknown service" error that's easy to miss in a hurry.

In your second terminal (keep the first one open), confirm password login is actually rejected:

ssh -o PubkeyAuthentication=no username@your-server-ip

This forces the connection attempt to skip your key. You should be refused immediately rather than prompted for a password. If you are still prompted, go back to Step 4 — there's an override file somewhere still allowing it.

Only close your original session once this verification step passes.

What this does and doesn't protect against

Key-only SSH removes the single most common attack vector on a fresh VPS, but it's one layer, not a complete security posture. It doesn't protect against:

• A compromised local machine. If your laptop is compromised, your private key can be too — treat it like a password and consider a passphrase on the key itself.
• Vulnerabilities in whatever you deploy. SSH hardening doesn't touch your web application, database, or the containers running on the box.
• Everything else listening on the server. Pair this with a firewall (UFW is the simplest starting point on Ubuntu) that only allows the ports you actually need public.

If you're already running multiple services or apps on the same VPS, our guide on hosting multiple apps on one VPS with Docker and Caddy covers keeping only 80 and 443 exposed while everything else stays internal — the same "close what you don't need open" principle applied one layer up.

If you get locked out anyway

Don't panic — you haven't lost the server, just SSH access to it. Every major VPS provider (DigitalOcean, Hetzner, AWS, Linode, Vultr) offers a browser-based console in their dashboard that connects directly to the VM, bypassing SSH entirely. Log in there, fix whichever config file is wrong, restart the SSH service, and try again from your terminal.

Commands and file paths in this guide were verified against current Ubuntu documentation in August 2026. The general approach (key setup, PasswordAuthentication no, checking for override files) applies to Debian and most other distributions too, though exact file locations can vary slightly.