Setting Up SSH Key Authentication on Ubuntu

SSH key authentication replaces passwords with a cryptographic key pair. The private key stays on your local machine and is never transmitted over the network, meaning an attacker who intercepts your connection cannot use anything they capture to log in. On a server open to the internet, disabling password authentication entirely removes one of the most commonly exploited attack vectors.

This guide walks through generating a key pair on your local machine, copying the public key to your server, and disabling password login once key authentication is confirmed working. It assumes you have a running Ubuntu server with a non-root sudo user. If not, complete the Ubuntu 24.04 initial setup guide first.

How SSH Key Authentication Works

When you generate a key pair, you get two files: a private key that stays on your local machine, and a public key that you place on the server. When you connect, the server challenges your SSH client to prove it holds the matching private key. The private key never leaves your machine during this exchange; the authentication happens through cryptographic proof rather than by transmitting a secret.

Step 1 - Generating a Key Pair

In this step, you will generate a key pair on your local machine. Run this command locally, not on the server:

ssh-keygen -t ed25519 -C "[email protected]"

When prompted, accept the default location (~/.ssh/id_ed25519) or specify a different path. Set a passphrase when asked; this protects the key if your local machine is ever compromised. You now have a private key at ~/.ssh/id_ed25519 and a public key at ~/.ssh/id_ed25519.pub.

Step 2 - Copying the Public Key to the Server

The public key needs to be added to the authorized_keys file on your server. The simplest way to do this is with ssh-copy-id:

ssh-copy-id [email protected]

This appends your public key to ~/.ssh/authorized_keys on the server. If ssh-copy-id is not available on your system, copy the key manually:

cat ~/.ssh/id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Either method produces the same result: your public key is on the server and your SSH client will offer the matching private key on the next connection.

Step 3 - Testing Key-Based Login

Before disabling password authentication, confirm that key-based login is working. Open a new terminal window and connect:

ssh [email protected]

If the connection succeeds without prompting for a password, key authentication is working. Do not close your existing SSH session until you have confirmed this in the new terminal.

Step 4 - Disabling Password Authentication

With key authentication confirmed, you can now disable password logins. Do not proceed with this step until key-based login is verified working; disabling passwords without a working key will lock you out and require recovery via your provider's web console.

On the server, edit /etc/ssh/sshd_config and set:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin no

Restart the SSH daemon to apply the changes:

systemctl restart sshd

Your server now only accepts connections from machines holding a key in its authorized_keys file. Password-based login is disabled entirely.

Managing Multiple Keys

If you connect to multiple servers, an SSH config file lets you define named shortcuts so you do not need to type the full connection string each time. Create or edit ~/.ssh/config on your local machine:

Host my-vps
    HostName your.server.ip
    User deploy
    IdentityFile ~/.ssh/id_ed25519

With this in place, you can connect with:

ssh my-vps

If You Get Locked Out

If you disable password authentication before confirming key auth is working, you will not be able to log in via SSH. Most VPS providers offer a web-based console in their control panel that bypasses SSH entirely. Log in via the console, re-enable password authentication in /etc/ssh/sshd_config, restart the SSH daemon, and then start this guide again from step 2.

Your Server Is Secured

You now have SSH key authentication in place and password logins disabled, which removes the most common method of unauthorised server access. The next step in hardening the server is to configure a firewall; follow the UFW and Fail2Ban guide to set that up.