Configure SSH Key Authentication on Ubuntu VPS
Why SSH Keys Beat Passwords for VPS Access
Password-based SSH logins are the first thing automated scanners probe when your server comes online. Within minutes of provisioning a new VPS, bots are already hammering port 22 with credential lists. SSH key authentication sidesteps all of that — a key pair that isn't on the attacker's machine simply can't be guessed.
Keys are also practical. You stop typing passwords on every login. Deployment scripts authenticate without stored credentials. And when a team member leaves, you delete their specific key rather than rotating a shared password across every system.
This tutorial covers the full setup for SSH key authentication on Ubuntu VPS — generating a key pair, copying the public key to your server, locking down sshd_config, and testing before you close anything. If you're running a Hostperl VPS, this is one of the first hardening steps worth doing after initial provisioning.
What You'll Need Before Starting
- An Ubuntu 22.04 or 24.04 VPS with root or sudo access
- A local machine running Linux, macOS, or Windows (with OpenSSH or PuTTY)
- An existing password-based SSH session open — keep it open until you've confirmed key login works
That last point matters. If you close your session before testing, you can lock yourself out. Always verify key authentication works in a second terminal before disabling passwords.
Step 1: Generate an SSH Key Pair on Your Local Machine
On Linux or macOS, open a terminal and run:
ssh-keygen -t ed25519 -C "your@email.com"Ed25519 is the recommended algorithm in 2026 — faster than RSA, shorter keys, and equivalent or better security. If your client software is older and doesn't support it, fall back to -t rsa -b 4096.
The command prompts you for a file path. The default (~/.ssh/id_ed25519) works fine for most setups. You'll also be asked for a passphrase — use one. It encrypts the private key file so that stealing the file alone isn't enough to compromise your server.
After completion, you'll have two files:
~/.ssh/id_ed25519— your private key. Keep this on your local machine only.~/.ssh/id_ed25519.pub— your public key. This goes on the server.
Windows Users
OpenSSH ships with Windows 10 and 11 by default. Open PowerShell and run the same ssh-keygen command above. Keys land in C:\Users\YourName\.ssh\. PuTTY users should generate keys with PuTTYgen and export the public key in OpenSSH format.
Step 2: Copy the Public Key to Your Ubuntu VPS
The cleanest method is ssh-copy-id. It appends your public key to the right file with correct permissions automatically:
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@your-server-ipReplace username with your actual user (often ubuntu or root on a fresh VPS) and your-server-ip with your server's IP address. You'll be prompted for your password one last time.
If ssh-copy-id isn't available, do it manually on the server:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keysPaste the full contents of id_ed25519.pub on its own line, save, then set permissions:
chmod 600 ~/.ssh/authorized_keysPermissions aren't optional. SSH will refuse to use authorized_keys if the file is world-readable or group-writable — a common stumbling block when copying keys by hand.
Step 3: Test Key Login Before Changing Anything Else
Open a new terminal window — don't close your existing session. Try connecting with your key:
ssh -i ~/.ssh/id_ed25519 username@your-server-ipIf you set a passphrase, you'll be prompted for it. You should land in a shell without being asked for your account password.
If it fails, check the ~/.ssh/ directory permissions on the server and confirm the key contents in authorized_keys look right before moving on.
This is the most important step in the whole process. Skipping it and immediately disabling password auth is how people end up locked out of their servers at 2am.
Step 4: Disable Password Authentication in sshd_config
Once key login is confirmed, open the SSH daemon config on your server:
sudo nano /etc/ssh/sshd_configFind and update these three lines. If they're commented out with a #, uncomment them and set the values:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-passwordprohibit-password allows root login via key only, which is useful on root-only VPS setups. If you have a regular sudo user, set it to no and log in as that user instead.
On Ubuntu 22.04 and 24.04, check for drop-in config files that might override your changes:
ls /etc/ssh/sshd_config.d/Files like 50-cloud-init.conf sometimes contain PasswordAuthentication yes, which overrides your main config. Either remove the file or update that line directly inside it.
Once done, reload the SSH daemon:
sudo systemctl reload sshDepending on the Ubuntu version, the service may be called sshd rather than ssh — if one doesn't work, try the other. Use reload, not restart, so your existing sessions stay connected.
Step 5: Verify the Configuration Holds
From a third terminal — still keeping your original session open — try connecting with a password explicitly:
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no username@your-server-ipYou should see Permission denied (publickey). That confirms password auth is off. Try your key login once more to make sure everything still works, then close your original session.
Managing Multiple Keys and Team Access
For team access, add each person's public key as a separate line in ~/.ssh/authorized_keys. One key per line, no blank lines between them. To cut off a specific person, delete their line and reload SSH — their access stops immediately, no password change needed anywhere.
On servers where multiple users need individual accounts — common in agency or shared environments — create a separate Linux user for each person and manage their ~/.ssh/authorized_keys individually. This gives you a clean audit trail. The guide on VPS access management for hosting teams covers the broader strategy if you're managing multiple clients on one server.
Using ssh-agent to Avoid Repeated Passphrase Prompts
A passphrase-protected key is more secure, but typing it on every connection gets old fast. ssh-agent holds your decrypted key in memory for the duration of your session:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519Enter your passphrase once. SSH connections for the rest of the session use the agent automatically. On macOS, add the key with --apple-use-keychain to persist it across reboots. On Linux, most desktop environments start an agent automatically.
Pairing SSH Keys with Other Security Measures
Key-based authentication cuts your attack surface significantly, but it works best alongside other baseline hardening. Moving SSH off port 22 reduces automated scan noise. Restricting which IPs can reach that port tightens things further — the UFW firewall setup guide covers that in detail.
Fail2Ban still makes sense even with key auth in place — it protects other services on the server, not just SSH. The Fail2Ban setup guide for Ubuntu VPS is a natural next step after this one.
For a broader view of what to lock down after launch, the VPS security checklist covers the full picture without drowning you in advanced tooling.
Need a solid foundation to build on? Hostperl VPS plans come with full root access, clean Ubuntu installs, and support that actually picks up the phone — so you can apply hardening like this without fighting your host. If your workload has outgrown a VPS, dedicated server options are worth a look for the extra headroom.
Frequently Asked Questions
What happens if I lose my private key?
If you lose your private key and have no other authorized key or console access, you'll need to use your hosting provider's out-of-band console (VNC or KVM) to re-enable password auth temporarily, add a new key, then lock it down again. Hostperl's control panel provides console access for exactly this scenario. Keep a backup of your private key somewhere secure — an encrypted password manager works well.
Can I use the same key pair for multiple servers?
Yes. Copy the same public key to authorized_keys on each server. The tradeoff is that a compromised private key affects all of them at once. Many sysadmins generate one key pair per device — laptop, workstation — rather than per server. That way, revoking a lost device means removing one key from each server, not regenerating everything.
Does this work the same way for root versus a regular sudo user?
The process is identical — the authorized_keys file just lives in a different home directory. For root it's /root/.ssh/authorized_keys; for a user named deploy it's /home/deploy/.ssh/authorized_keys. Permissions must be correct in either case.
Should I disable root login entirely?
On production servers, yes. Create a regular user with sudo privileges and set PermitRootLogin no. It adds one more obstacle for an attacker even if they somehow obtain a valid key. On a freshly provisioned VPS where you haven't created a sudo user yet, use prohibit-password as an interim setting while you get that user set up.
