Module 2 · 2.1

English

Nederlands English Deutsch Français

Creating and using SSH keys

Module 2: SSH and keys · Reading time: 10 minutes

Learning objective: After this lesson you can create a key pair, put the public key on your server, log in without a password and store your private key so that a lost laptop is not a disaster.

Key concepts: key pair, public key, private key, ed25519, RSA, passphrase, ssh-agent, ssh-copy-id, authorized_keys, permissions 700 and 600, one key per device, FIDO2 key

Why keys are better than passwords

In lesson 1.3 you logged in with a password. That works, but a server on the internet gets visits from password-guessing programs from the very first minute. Just take a look at the log of a fresh server:

root@web1:~# journalctl -u ssh --since "1 hour ago" | grep -c "Failed password"
214

Hundreds of attempts per hour is normal. A strong password stops them, but you have created a weak spot you don't need. With an SSH key, guessing is pointless: there is nothing to guess that appears in a word list.

A key consists of two parts that belong together, a key pair:

The private key stays on your own computer. Anyone who has this file (and knows the passphrase) can log in. Share it with no one, not even your provider or a helpdesk.
The public key is what you give to the server. Anyone may see it: you can't log in with it, only verify.

When you log in, the server doesn't send a password over the line. Your computer proves with a signature that it has the private key, and the server checks that signature with the public key. Even if someone is watching the network, they see nothing they can reuse later.

Creating a key

You create the key on your own computer, not on the server. Windows 10 and 11, macOS and Linux already include ssh-keygen. Open PowerShell or Terminal:

anna@laptop:~$ ssh-keygen -t ed25519 -C "anna@laptop 2026"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/anna/.ssh/id_ed25519):
Enter passphrase for "/home/anna/.ssh/id_ed25519" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/anna/.ssh/id_ed25519
Your public key has been saved in /home/anna/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:q3J8vX0bT2kPz9mWc1nR4sLh7uYdE5aF6gBiC0oN2xQ anna@laptop 2026

What happens here?

-t ed25519 chooses the type. Ed25519 is short, fast and secure, and since OpenSSH 9.5 it is also the default type if you don't specify one. If you have to serve an old system that doesn't know ed25519, use RSA with at least 3072 bits: ssh-keygen -t rsa -b 4096. Older types such as DSA have been removed from OpenSSH; don't use them.
-C is just a comment. Put something in it that tells you later which device the key belongs to. That helps enormously when you need to revoke a key.
The passphrase encrypts the private key on your disk. If your laptop is stolen, the thief has an encrypted file. Without a passphrase, they have immediate access to all your servers.

You now have two files:

File	What	Share?
`~/.ssh/id_ed25519`	Private key	Never
`~/.ssh/id_ed25519.pub`	Public key, one line of text	Yes, to the server

On Windows they are in C:\Users\anna\.ssh\. The public key is one line that starts with ssh-ed25519:

anna@laptop:~$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHk2... anna@laptop 2026

Putting the public key on the server

The server looks for public keys in the file ~/.ssh/authorized_keys of the user you log in as. Each line is one key. There are three ways to get your key there:

1. During installation. Most providers have a field for your public key when you create or reinstall a VPS. At WebOké this field is called "SSH key" in the VPS screen; other providers work in a similar way. This is the best way: then password login never has to be switched on.

2. With ssh-copy-id (macOS and Linux), while password login still works:

anna@laptop:~$ ssh-copy-id anna@192.0.2.10
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed
anna@192.0.2.10's password:
Number of key(s) added: 1

3. By hand, for example from Windows or via your provider's console. Paste the line from your .pub file into authorized_keys and set the permissions correctly:

anna@web1:~$ mkdir -p ~/.ssh
anna@web1:~$ nano ~/.ssh/authorized_keys
anna@web1:~$ chmod 700 ~/.ssh
anna@web1:~$ chmod 600 ~/.ssh/authorized_keys

Those permissions are not a detail. The SSH server checks them (the setting StrictModes is on by default): if others are allowed to write to your .ssh folder or your home directory, it ignores your keys. You then simply see a password prompt again, without a clear error message. You'll learn how to read permissions in lesson 3.1.

Then test in a new window:

anna@laptop:~$ ssh anna@192.0.2.10
Enter passphrase for key '/home/anna/.ssh/id_ed25519':
anna@web1:~$

The prompt now comes from your own computer (the passphrase of your key), no longer from the server.

ssh-agent: unlock once

Typing a passphrase every time is a nuisance. The ssh-agent keeps your unlocked key in memory as long as you are logged in on your computer:

anna@laptop:~$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/anna/.ssh/id_ed25519:
Identity added: /home/anna/.ssh/id_ed25519 (anna@laptop 2026)
anna@laptop:~$ ssh-add -l
256 SHA256:q3J8vX0bT2kPz9mWc1nR4sLh7uYdE5aF6gBiC0oN2xQ anna@laptop 2026 (ED25519)

On macOS the agent links to the Keychain; on Windows it is the "OpenSSH Authentication Agent" service (switch it on once in Services). This gives you the convenience of no password while still keeping an encrypted key on disk.

Be careful with agent forwarding (ssh -A): it lets the server you log in to use your agent. Anyone who is root on that server can then carry on with your key. Only use it on servers you trust completely, or use ProxyJump (lesson 2.3).

One key per device, and knowing which are where

A common mistake: copying one private key to your laptop, PC and phone. If you lose one device, you have to replace the key everywhere and set up all devices again. Better:

create a separate key on each device, with a clear comment (-C "anna@telefoon");
put all public keys in authorized_keys, one per line;
if you lose a device, remove only that one line.

Regularly check which keys have access:

anna@web1:~$ ssh-keygen -lf ~/.ssh/authorized_keys
256 SHA256:q3J8vX0bT2kPz9mWc1nR4sLh7uYdE5aF6gBiC0oN2xQ anna@laptop 2026 (ED25519)
256 SHA256:Zt5oP1yW8eQ3rK6sV0bN9mD2xA4cH7jL1uI5fG8tE3w anna@telefoon (ED25519)

If there is a key you don't recognise, that is a warning sign (lesson 10.3). Intruders like to put their own key in authorized_keys so they can come back later.

A hardware key (FIDO2, such as a YubiKey) is also an option. With ssh-keygen -t ed25519-sk the secret part lives on the key itself and you have to touch it every time you use it. A stolen file is then worthless. That is a nice step further, but not necessary to get started.

Lost your private key?

If you lose your only private key and password login is switched off, you can no longer get in via SSH. So:

always put at least two keys on the server (for example laptop and PC);
know how your provider's console works (lesson 1.2). There you log in as if you had plugged a keyboard into the server, and that works without SSH too. At WebOké this is called Console in the VPS screen; other providers call it VNC console, web console or emergency console.

On AlmaLinux and Rocky Linux

Everything in this lesson works the same. One extra pitfall: with SELinux on, ~/.ssh must have the correct security label. If you created or copied the folder by hand and your key is ignored, restorecon -Rv ~/.ssh fixes that.

Summary

A key pair consists of a private key (stays with you) and a public key (goes to the server, in ~/.ssh/authorized_keys).
Create keys with ssh-keygen -t ed25519 on your own computer, with a passphrase; use ssh-agent for convenience.
Permissions matter: ~/.ssh at 700 and authorized_keys at 600, otherwise the server ignores your key.
One key per device, with a clear comment, so you can revoke just one.
Make sure you have a second key and know your provider's console as an emergency entrance.

Quiz

Exercise

Exercise O2.1: Creating and using a key. On your own computer, create an ed25519 key with a passphrase and a clear comment, put it on your server (via your provider's field, ssh-copy-id or by hand), check the permissions and log in with the key in a new window. Then enter the fingerprint of your key (from ssh-keygen -lf ~/.ssh/id_ed25519.pub) and answer the questions about where your private key is stored and what you do if you lose it. The program only checks whether the fingerprint has the right format; the rest is up to you.

Exercise O2.1: Creating and using a key

You do this exercise yourself; no one checks it. Tick off what you've done and mark the exercise as done.

ed25519 key created on my own computer, with a passphrase
Comment (-C) that tells me which device it is
Public key placed on the server
Permissions checked: ~/.ssh 700, authorized_keys 600
Logged in with the key in a new window
Second key on the server, or I know how to use my provider's console

Where is your private key stored, and who else can get to it?

What do you do if your laptop with this key is stolen?

Which error message did you get along the way, and what was the fix?

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing