How I Secured My Ubuntu 24.04 Server with SSH Key Authentication

As a dedicated DevOps Engineer, I've immersed myself in the dynamic world of DevOps, sharing my insights through blogs to support the community. I aim to simplify complex processes, empowering both beginners and experts to navigate DevOps with confidence and ease, fostering collective growth in this ever-evolving field.
If you're running a home server or any Linux machine that's accessible over the internet, password authentication is a ticking time bomb. Automated bots are constantly scanning for SSH servers and attempting brute-force attacks. The solution? SSH key-based authentication.
In this guide, I'll walk you through exactly how I set up SSH key authentication on my Ubuntu 24.04 LTS server, including a frustrating quirk that had me scratching my head until I figured out what was going on.
What We're Going to Accomplish
By the end of this guide, you'll have:
A secure SSH key pair generated on your local machine
Key-based authentication working on your server
Password authentication completely disabled
A backup strategy so you don't lock yourself out
My Setup:
Server: Ubuntu 24.04 LTS
Local Machine: Linux (commands are similar for macOS; Windows users can use PowerShell or WSL)
SSH Port: Custom port (not the default 22)
Prerequisites
Before we start, make sure you have:
SSH access to your Ubuntu server (currently with password authentication)
A local Linux or macOS machine (or Windows with WSL/PowerShell)
Basic familiarity with the terminal
Step 1: Generate Your SSH Key Pair
The first step happens on your local machine — not the server.
Open your terminal and run:
ssh-keygen -t ed25519 -C "yourname@your-server"
What does this do?
| Flag | Purpose |
-t ed25519 | Uses the Ed25519 algorithm — modern, secure, and faster than RSA |
-C "yourname@your-server" | Adds a comment to help you identify the key later |
You'll be prompted for:
File location — Press Enter to accept the default (
~/.ssh/id_ed25519), or specify a custom path like~/.ssh/myserver/keyPassphrase — I strongly recommend setting one. This encrypts your private key, so even if someone steals the file, they can't use it without the passphrase.
Pro tip: I like to organize my keys by creating subdirectories. For example:
mkdir -p ~/.ssh/homelab
ssh-keygen -t ed25519 -C "homelab-server" -f ~/.ssh/homelab/homelab
This creates:
~/.ssh/homelab/homelab— your private key (never share this!)~/.ssh/homelab/homelab.pub— your public key (this goes on the server)
Verify your keys were created:
ls -la ~/.ssh/
# Or if you used a custom directory:
ls -la ~/.ssh/homelab/
You should see two files. The private key should have permissions 600 (readable only by you):
-rw------- 1 user user 464 Jan 19 21:20 homelab
-rw-r--r-- 1 user user 101 Jan 19 21:20 homelab.pub
Step 2: Copy Your Public Key to the Server
Now we need to get your public key onto the server. The easiest way is using ssh-copy-id.
Run this on your local machine:
ssh-copy-id -i ~/.ssh/homelab/homelab.pub -p 22 youruser@your-server-ip
Adjust the command for your setup:
-i— path to your public key (note the.pubextension)-p— your SSH port (22 is default, but use your custom port if you changed it)youruser@your-server-ip— your username and server address
You'll be asked for your server password one last time. After that, the tool will:
Connect to your server
Create the
~/.sshdirectory if it doesn't existAppend your public key to
~/.ssh/authorized_keysSet the correct permissions
You should see output like:
Number of key(s) added: 1
Step 3: Test Key-Based Authentication
Before we disable password authentication, let's make sure key-based login actually works.
Run this on your local machine:
ssh -i ~/.ssh/homelab/homelab -p 22 youruser@your-server-ip
What should happen:
If you set a passphrase on your key, you'll be prompted for it
You should NOT be asked for your server account password
You should be logged in!
Test from different networks too. If you're setting this up for remote access (like through a DDNS domain), make sure to test that connection as well:
ssh -i ~/.ssh/homelab/homelab -p 22 youruser@your-ddns-domain.com
Step 4: Disable Password Authentication
This is where things get interesting — and where Ubuntu 24.04 threw me a curveball.
⚠️ Important: Keep your current SSH session open throughout this process. We'll test changes from a new terminal window. If something goes wrong, your existing session stays connected so you can fix it.
Check the Current Configuration
On the server, let's see what the current settings look like:
sudo grep -E "^#?PasswordAuthentication|^#?KbdInteractiveAuthentication" /etc/ssh/sshd_config
You might see something like:
#PasswordAuthentication yes
KbdInteractiveAuthentication no
The # means the line is commented out, so it's using the default value (which is yes for PasswordAuthentication).
Edit the Main Config File
Let's change PasswordAuthentication to no:
sudo sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
Verify the change:
sudo grep -E "^PasswordAuthentication" /etc/ssh/sshd_config
You should see:
PasswordAuthentication no
Restart SSH
sudo systemctl restart ssh
Test... Wait, Why Is It Still Working?
Here's where I got confused. I opened a new terminal and tried to connect with password-only authentication:
ssh -p 22 -o IdentitiesOnly=yes -o PreferredAuthentications=password youruser@your-server-ip
This command forces SSH to only try password authentication (no keys). It should fail with Permission denied (publickey).
But for me? It still asked for my password. And let me in.
The Ubuntu 24.04 Gotcha: Override Files
After some investigation, I found the culprit. Ubuntu 24.04 uses drop-in configuration files that can override your main sshd_config settings.
Check for override files:
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
And there it was:
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes
The 50-cloud-init.conf file was setting PasswordAuthentication yes, and because files in sshd_config.d/ are loaded after the main config, it was overriding my change.
Fix the Override
sudo sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config.d/50-cloud-init.conf
Verify:
cat /etc/ssh/sshd_config.d/50-cloud-init.conf
You should see PasswordAuthentication no.
Restart SSH Again
sudo systemctl restart ssh
Now Test Again
From a new terminal on your local machine:
ssh -p 22 -o IdentitiesOnly=yes -o PreferredAuthentications=password youruser@your-server-ip
This time you should see:
youruser@your-server-ip: Permission denied (publickey).
Password authentication is now disabled.
Step 5: Verify Key-Based Access Still Works
Just to be safe, let's confirm you can still log in with your key:
ssh -i ~/.ssh/homelab/homelab -p 22 youruser@your-server-ip
You should get in without any issues. If you set a passphrase, you'll be asked for that (which is your key passphrase, not your server password).
Backup Strategies: Don't Lock Yourself Out
With password authentication disabled, your private key is the only way in. Here's how to protect yourself:
Option 1: Backup Your Key Files
Copy your private key to secure storage:
A USB drive kept in a safe place
A password manager that supports file attachments (like Bitwarden or 1Password)
Encrypted cloud storage
# Create a backup copy
cp -r ~/.ssh/homelab ~/.ssh/homelab-backup
# Or copy to a USB drive
cp -r ~/.ssh/homelab /media/usb/ssh-backup/
Option 2: Generate Keys on Multiple Devices
Instead of copying your private key around (which increases risk if one device is compromised), you can generate separate key pairs on each device:
Generate a new key pair on your laptop
Generate another on your desktop
Generate one on your phone (if using an SSH app like Termius)
Then add all public keys to your server's ~/.ssh/authorized_keys file. This way, if you lose one device, you still have access from others.
Option 3: Physical Access Fallback
If you have physical access to your server (like a home server), you can always plug in a monitor and keyboard to recover if you're completely locked out. This is my ultimate fallback — it's why I feel comfortable being aggressive with security on my home server.
Quick Reference: Connecting to Your Server
Once everything is set up, here are the commands you'll use:
# Basic connection
ssh -i ~/.ssh/homelab/homelab -p 22 youruser@your-server-ip
# Or via DDNS domain
ssh -i ~/.ssh/homelab/homelab -p 22 youruser@your-domain.com
Simplify with SSH Config (Optional)
Create or edit ~/.ssh/config on your local machine:
Host myserver
HostName your-server-ip
User youruser
Port 22
IdentityFile ~/.ssh/homelab/homelab
Now you can simply type:
ssh myserver
Key Takeaways
Ed25519 is the modern choice — It's more secure and faster than RSA, with shorter keys.
Always test before disabling password auth — Keep an existing SSH session open while making changes.
Ubuntu 24.04 uses override files — Check
/etc/ssh/sshd_config.d/if your changes don't seem to take effect. The50-cloud-init.conffile often setsPasswordAuthentication yesby default.Backup your private key — Without it, you're locked out. Store it securely in multiple locations.
Consider separate keys per device — More secure than copying one key everywhere.
Use a passphrase — Encrypts your private key, adding another layer of protection.
Summary Table
| What | Where |
| Private key | ~/.ssh/id_ed25519 (or custom path) on local machine |
| Public key | ~/.ssh/authorized_keys on server |
| Main SSH config | /etc/ssh/sshd_config on server |
| Override configs | /etc/ssh/sshd_config.d/*.conf on server |
| Restart SSH | sudo systemctl restart ssh |
Final Thoughts
Setting up SSH key authentication felt like a straightforward task until Ubuntu 24.04's configuration override tripped me up. It's a good reminder to always verify that changes actually took effect, especially on newer OS versions that might handle things differently than expected.
With key-based authentication enabled and password access disabled, your server is now significantly more secure against brute-force attacks. Automated bots can scan and probe all they want — without your private key, they're not getting in.
Happy securing! 🔐
Found this helpful? Have questions? Drop a comment below or connect with me on [your social platform]. I'm always happy to chat about homelab setups and DevOps adventures.





