Keys

A key is, at its core, a very large number generated by a sophisticated mathematical process. Private keys are typically hundreds or thousands of bits long. Printed out, a single key would fill multiple pages of what looks like nonsense. No human is memorising that, which is why keys live in files rather than heads.

The problem with keeping a secret in a file is that files can be copied, stolen, or accidentally committed to a git repository. The solution is to encrypt the key file itself with a passphrase, so that even if someone gets hold of the file, it is useless to them without the passphrase that unlocks it. This is why the passphrases section came first.

SSH keys

SSH key pairs are how you authenticate to remote servers without typing a password every time. The private key stays on your machine. The public key goes on any server you want access to. When you connect, the server challenges your client to prove it holds the private key, and the cryptographic handshake handles the rest. No password ever travels across the network.

ed25519

Ed25519 is the right choice for new SSH keys. It is fast, produces small keys and signatures, and its security properties are well understood. The compatibility concerns that existed when it was introduced in 2014 are largely no longer relevant. Any server or device you are likely to interact with in this setup will support it.

Generate an ed25519 key with:

ssh-keygen -t ed25519 -a 100

The -a 100 flag sets the number of key derivation rounds used to protect the private key file. Higher values make the passphrase harder to brute force at the cost of a slightly slower unlock. 100 is a reasonable balance.

You will be prompted for a file location (the default ~/.ssh/id_ed25519 is fine) and a passphrase. Use a six-word Diceware passphrase here, as covered in the previous section.

The output will look something like:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX user@host

The .pub file is your public key. This is the one you distribute to servers. The file without the extension is your private key. It never leaves your machine.

RSA

RSA keys are the older standard and are still worth generating if you need to connect to legacy systems that do not support ed25519. If that does not apply to your setup, you can skip this.

If you do need an RSA key, generate it at 4096 bits. The default of 2048 is considered marginal by current standards:

ssh-keygen -t rsa -b 4096 -a 100

Save it to a different filename than your ed25519 key, for example ~/.ssh/id_rsa, and protect it with a strong passphrase.

Key storage and permissions

SSH is strict about key file permissions. If the private key file is readable by anyone other than the owner, SSH will refuse to use it. Kubuntu sets these correctly when the key is generated, but worth knowing if you ever copy a key from another machine:

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

The ~/.ssh directory itself should be 700:

chmod 700 ~/.ssh

SSH agent

Typing your key passphrase every time you open an SSH connection gets old quickly. The SSH agent handles this by holding your unlocked key in memory for the duration of your session. KDE Plasma includes a wallet-integrated SSH agent that prompts you for your passphrase once at login and handles it from there.

To add your key to the agent manually:

ssh-add ~/.ssh/id_ed25519

You will be prompted for the passphrase once. After that, SSH connections will use the key silently until you log out.

Distributing your public key

To copy your public key to a remote server:

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

This appends your public key to ~/.ssh/authorized_keys on the remote machine. Once done, SSH connections to that server will use your key rather than a password.

Never copy your private key to a remote server. If you need the same key accessible from multiple machines, copy it via encrypted transfer and protect it identically on each machine. Better still, generate a separate key per machine and add each public key to the server individually.

Key organisation

As the number of servers in this setup grows, it is worth being deliberate about key management from the start. The options are a single key used everywhere, or a key per machine or per purpose.

A single key is simpler. It is also a single point of failure: if the key is compromised, every server it is authorised on is compromised. Separate keys per machine mean that a compromised laptop does not also compromise your desktop, and revoking access for a lost device is a matter of removing one key from each server’s authorized_keys rather than rotating everything everywhere.