SSH keys, properly

SSH key authentication is the standard way to access a server, and most people set it up once by following a tutorial and never revisit it. That is usually fine, until a laptop is lost, or someone leaves the team, or a key from four years ago turns out to still grant access to production.

None of the improvements below are difficult. Together they take an afternoon at most and remove a category of problem.

Choose the right key type

Ed25519 is the current sensible default. Keys are short, generation is fast, verification is fast, and the security properties are excellent. It is supported everywhere that matters.

RSA remains acceptable if something in your environment requires it, but use at least 3072 bits and preferably 4096. Older DSA and ECDSA keys should be replaced.

If you have a key generated years ago and cannot remember what type it is, that is itself a good reason to generate a new one.

Always use a passphrase

A private key without a passphrase is a plaintext credential. Anyone who obtains the file has your access, immediately and silently.

The objection is that typing a passphrase constantly is intolerable, and it would be. That is what an SSH agent is for: unlock the key once per session and the agent holds it in memory. Every operating system ships one, and desktop environments integrate with the keychain so it is often a single prompt after login.

Setting an agent timeout means the key is forgotten after a period of inactivity, which is a reasonable middle ground.

One key per device, not one key per person

The instinct is to generate a key and copy it to every machine you use. Resist it, for one reason: revocation.

With one key on four devices, losing one device means rotating that key everywhere it is authorised, on every server, immediately.

With a separate key per device, losing a laptop means removing one public key from the authorised lists. Everything else continues working, and there is no emergency.

The extra effort is one key generation per device and one extra line in each server’s authorised keys file. The saving arrives on the worst day.

Do not carry private keys around

Copying a private key to a server so you can hop from there to another server is a common shortcut and a bad one. It puts the credential on a machine that may be less trusted than your laptop.

Agent forwarding lets a remote session use your local agent without the key ever leaving your machine. It has its own caveat: root on the intermediate host can use the forwarded agent while your session is open, so forward only to hosts you trust.

For more complex paths, a jump-host configuration in your SSH client is cleaner than forwarding, because it connects through the intermediate host without exposing the agent to it at all.

Use the client configuration file

An SSH configuration file turns long, error-prone commands into short names, and it is where the good defaults live.

Per-host entries can specify which key to use, which user, which port, and which jump host to route through. Once configured, connecting is a single short command, and the correct key is chosen automatically rather than the client offering every key you own to every server.

That last point has a practical benefit: offering many keys to a server can hit authentication attempt limits and fail confusingly. Specifying the identity per host avoids it.

Rotate, and actually remove old keys

Authorised key files accumulate. Keys added for a contractor, for an old laptop, for a colleague who has since left, all sit there indefinitely because removing them is nobody’s task.

Two habits fix this. Review authorised keys on your servers periodically, perhaps twice a year, and remove anything you cannot positively identify. And add a comment to every public key identifying the person and the device, because a key you cannot identify is a key you will not dare remove.

For teams beyond a handful of people, managing authorised keys by hand stops scaling. That is the point to move to configuration management, or to certificate-based SSH where keys are signed by an authority and expire automatically, which removes revocation as a manual task entirely.

Hardware keys, when the access is serious

A key stored on a hardware token cannot be copied off it. For access to production infrastructure, this closes the remaining gap, because even a fully compromised laptop does not yield the private key.

Modern SSH supports hardware-backed key types directly, and the setup is not much harder than a normal key. For a small number of high-value access paths, it is worth the effort.

A quick self-audit

• Do you know how many private keys you have, and where each one is?
• Does every private key have a passphrase?
• Could you list which servers each key can reach?
• If you lost your laptop right now, what would you have to do, and how long would it take?
• When did you last look at an authorised keys file on a production server?

If the last two answers are uncomfortable, an afternoon of tidying is a good investment.

The same reasoning applies across providers. The catalogue of cloud accounts sets out where each one fits, if you are still deciding which to build on.

For the vendor’s own reference on the services involved here, see the Linode documentation on Akamai TechDocs.

Working through this on a real server is worth the hour it takes. We stock Linode accounts in two configurations, and the cloud account catalogue compares all ten providers side by side.

Questions people ask