SSH key

That's not a detail. It means no password goes over the network that can be intercepted. It also means a brute-force attack on your SSH port becomes pointless: there's nothing to guess.

The price of that security is that your private key becomes the new attack surface. Someone who gets hold of your laptop and finds the key without a passphrase has access to everything that key grants access to. That's why a passphrase belongs on your key—more on that later.

Generating a key pair

Open a terminal on your client and type:

ssh-keygen -t ed25519 -a 100 -C "jouw@email.nl"

Ed25519 is the algorithm you want. It's faster than RSA, the keys are smaller, and the security is more thoroughly documented. The `-a 100` tells ssh-keygen to run the key through the KDF function 100 times; that makes a brute-force on your passphrase more expensive. The `-C` is a comment field, handy for later seeing which key serves what purpose.

The command asks where you want to store the key. The default location is `~/.ssh/id_ed25519`. You can keep that, unless you already have a key in that spot—don't overwrite it. Then it asks for a passphrase. You can leave it empty, but don't. A key without a passphrase is a text file that, once stolen, works immediately.

The output ends with a fingerprint and a "randomart image". Note that fingerprint somewhere; later you can use it to check that you're talking to the right server.

Installing the public key

The public key needs to go to the server, into the file `~/.ssh/authorized_keys` of the user you want to log in as. That can be done manually, but there's a command that does it for you:

ssh-copy-id -i ~/.ssh/id_ed25519.pub gebruiker@server.example.com

You'll have to type your password one more time; after that, `ssh-copy-id` copies the key to the right place and sets the permissions correctly. If your server runs on a different port than 22, add `-p ` to the command.

No `ssh-copy-id` on your system? Then paste the key manually. Display the public key with:

cat ~/.ssh/id_ed25519.pub

Copy the entire line and add it on the server to `~/.ssh/authorized_keys`. Create that directory if it doesn't exist:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "de-gekopieerde-public-key" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

The permissions aren't a formality. OpenSSH refuses to use keys from files that are readable by others. An `authorized_keys` with `chmod 644` simply won't work.

Logging in without a password

Now you can log in without a password:

ssh gebruiker@server.example.com

You now type your passphrase instead of your password. That seems like the same thing, but it isn't: the passphrase never leaves your machine. It only decrypts your private key in memory.

If you didn't set a passphrase, you now log in entirely without a prompt. Handy for scripts, but your private key then lies unencrypted on disk.

Not typing the passphrase every time

A passphrase you have to enter for every connection quickly becomes annoying, especially if you connect multiple times a day. `ssh-agent` remembers the decrypted key for your session.

Start the agent and add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

You type your passphrase once. After that, `ssh` uses the key from the agent for all connections, until you stop the agent or log out. On most Linux desktops, an ssh-agent is already running in your session; check with `ssh-add -l` whether keys are loaded.

This is also what you want for automation. A cron job that makes a backup via rsync can't type a passphrase interactively. With the agent loaded, it works without a prompt.

Disabling password authentication

You now have key authentication working. The next step is disabling password login on the server, because as long as that's on, brute-force remains a risk.

On the server, edit `/etc/ssh/sshd_config` as root:

sudo nano /etc/ssh/sshd_config

Add or adjust these lines:

PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no

The third line is important. Many systems use PAM for "keyboard-interactive" authentication, and that sometimes bypasses `PasswordAuthentication no`. With `KbdInteractiveAuthentication no`, you close that back door.

Then restart SSH:

sudo systemctl restart sshd

Before you close the current session: open a second terminal and test whether you can still log in with your key. If there is an error in your configuration, you will be locked out and will have to get back in via the console or a provider panel. That mistake will cost you an afternoon.

Verification

Check that everything works:

ssh -v gebruiker@server.example.com

In the output, look for a line like `Authenticated to server.example.com ([IP]:22)` and `Server accepts key`. If you see `Permission denied (publickey)`, the server is not accepting your key — check the permissions of `~/.ssh` and `authorized_keys` on the server.

A second check: look on the server to see if any password logins are still coming in:

sudo grep "Failed password" /var/log/auth.log | tail -20

After disabling password authentication, that list should stay empty, apart from attempts that were already running.

Common mistakes

The server does not accept the key. Check the permissions: `~/.ssh` must be `700`, `authorized_keys` `600`. Also check that you copied the public key and not the private one — the latter should never be on a server.

`ssh-copy-id` asks for a password for a different user. You are copying the key to the wrong account. Log in with the username you normally use and repeat the command.

You can no longer log in after disabling password auth. The sshd config contains an error or your key is not set up properly on the server. Log in via the console or an out-of-band solution, set `PasswordAuthentication` back to `yes`, restart sshd, and go through the steps again.

Keys do not work in a cronjob. Cron runs without your ssh-agent. Do not use a key without a passphrase for this purpose; create a separate key per task with its own passphrase and load it into an agent that the cronjob can reach, or use a tool like `keychain` to start the agent per session.

What you have now

You log in without a password over the network, your server is no longer open to brute-force attacks, and your private key is stored encrypted on your own machine. In case you were wondering: yes, this is also the way to secure Git-over-SSH and rsync backups. The same key works for that.

An SSH key is not a one-time setup. If your machine is stolen, you must remove the public key from all servers and generate a new pair. But that is an incident, not a daily concern. The daily concern — a password going over the network every time — is solved.