Tutoriel Linux

SSH key on Ubuntu: generate it properly before disabling passwords

Débutant4 min de lecture
À retenirLinux n'est pas réservé aux experts. Le bon point de départ : une distribution accessible, une sauvegarde propre et quelques commandes comprises.

If you administer an Ubuntu server via SSH, the public key must be ready before you touch password authentication. This is the point I too often see reversed: we harden sshdWe reload the service, then we discover that the key was never tested properly.

In this guide, we’re starting with a key ed25519We install the public key on the server, open a second session to test it, and only then disable passwords. It doesn’t take any longer, and it prevents you from locking yourself out.

Tux holds an SSH key in front of a secure Ubuntu server
An SSH key must be generated, copied, and tested before disabling password authentication.

Create an SSH key ed25519 on your computer

On your local machine, generate an ed25519 key. This is the format I would choose today for typical SSH administration.

ssh-keygen -t ed25519 -a 100 -C "admin@post"

The command asks you where to save the key. If you don’t already have a dedicated key, you can keep the suggested path:

~/.ssh/id_ed25519

Add a passphrase. On a laptop or a computer that leaves the office, I wouldn’t leave a private key unprotected. The passphrase protects the key if the file is copied or if the machine is compromised.

Next, verify that both files exist:

ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

The file without extension .pub is the private key. It must not be sent to the server, copied into a ticket, or shared. The file .pub is the public key, the one you will install on Ubuntu.

Install the public key on Ubuntu

If you still have password access, the simplest method is ssh-copy-id :

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

Replace user via the target SSH account, and server by IP address or name IN. The command adds your public key in ~/.ssh/authorized_keys server side.

If ssh-copy-id is not available, you can do it manually from an existing SSH session:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Paste a single line: the complete contents of your file id_ed25519.pubNever paste the private key. If you’re unsure, the public file usually starts with ssh-ed25519.

Test in a second session before closing the old one.

Do not close your current SSH session. Open a second terminal and test the connection with the key:

ssh -i ~/.ssh/id_ed25519 user@server

If you access the server without an account password, the key works. If the connection still asks for the user password, first check the permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

On Ubuntu, also check the SSH logs if the key is rejected:

sudo journalctl -u ssh -n 80 --no-pager

An incorrect folder owner, a key pasted across multiple lines, or a different target account are all enough to block authentication. Do not modify the SSH configuration until this step is complete.

Prepare sshd before disabling passwords

Before changing the configuration, back up the main file:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Next, check if there are any files in /etc/ssh/sshd_config.d/ already define authentication by key or password:

sudo grep -R "^PubkeyAuthentication|^PasswordAuthentication" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

On Ubuntu, I prefer to create a dedicated file rather than modify ten lines in the middle of the main file:

sudo nano /etc/ssh/sshd_config.d/99-disable-password.conf

Add:

PubkeyAuthentication yes
Password Authentication no

Before reloading SSH, test the syntax. This is non-negotiable on a remote server.

sudo /usr/sbin/sshd -t

If the command returns nothing, the syntax is valid. If it displays an error, correct it before reloading.

Reload SSH without cutting off your access

Once the syntax is validated, reload the service:

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

Keep the first session open. In a second terminal, retest the key-based connection:

ssh -i ~/.ssh/id_ed25519 user@server

Also test whether a keyless connection fails, if you have a test account or a machine where the key is not loaded. The goal is to verify the reality, not just read a configuration line.

If you’re using SSH on Ubuntu, keep the guide handy. restarting SSH on UbuntuAnd if you have a local firewall, also check your rules with the article on UFW before opening a server.

The checks that prevent the lockdown

  • the private key remains solely on your computer;
  • the public key is indeed in ~/.ssh/authorized_keys the right user;
  • the rights are correct on ~/.ssh And authorized_keys ;
  • a second SSH session per key works before any interruption;
  • sudo /usr/sbin/sshd -t returns no error;
  • The firewall is still allowing the correct SSH port.

If you lose SSH access after a change, you’ll have to use the recovery console, KVM, cloud provider access, or rescue mode. This method aims to prevent that. For a more comprehensive repair, you can also refer to the guide on a clean reinstallation of SSH on Ubuntu.

For official documentation, Ubuntu maintains a page on OpenSSHServerReference pages ssh-keygen And ssh-copy-id They also detail the options used here.

sudo apt update && sudo apt upgrade