Tooling

SSH key management is the practice of generating, protecting, distributing and retiring the cryptographic key pairs you use to log into servers over SSH. Done well, it replaces fragile passwords with keys that are far harder to guess, and lets you revoke access cleanly when a laptop is lost or a contractor leaves. Done badly — keys with no passphrase, copied between machines, never rotated — it quietly becomes one of the widest doors into your infrastructure.

The reason it deserves attention is that an SSH key is a standing credential. Unlike a password you type, a private key sits in a file on disk and grants access for as long as the matching public key stays in a server’s authorized_keys file. A single unprotected key, leaked from a backup or a compromised machine, can hand an attacker the same reach you have — which is exactly why developer and CI/CD keys are such a prized target.

How SSH keys actually work

An SSH key pair has two halves. The private key stays on your machine and must never leave it; the public key is copied to each server you want to reach, where it lives in ~/.ssh/authorized_keys. When you connect, the server challenges your client to prove it holds the private key, without the key itself ever crossing the network. Possession of that private file is therefore everything.

Modern practice favours the Ed25519 algorithm — short, fast and strong — over older RSA keys, though 3072-bit-or-larger RSA remains acceptable where Ed25519 is not supported. You generate a pair with ssh-keygen, and the single most important option is a passphrase: it encrypts the private key on disk, so that a stolen key file is useless to anyone who does not also know the phrase.

SSH key best practices

A handful of habits cover most of the risk. Always set a passphrase, and let ssh-agent hold the decrypted key in memory so you type it once per session rather than disabling it. Use a separate key per device instead of copying one private key across laptops, so you can revoke a single machine without disrupting the others. And give CI systems and servers their own keys, never your personal one.

• Always protect private keys with a passphrase
• Prefer Ed25519; use a separate key per device
• Give CI systems and servers their own keys
• Audit authorized_keys and remove stale access
• Rotate keys on a schedule and when a device is lost

Access is granted entirely by what sits in each server’s authorized_keys file, so that file is where management really happens. Review it periodically, remove keys for people and machines that no longer need access, and keep a short, named comment on each key so you can tell at a glance whose it is. Beyond a few servers, a configuration-management tool or an SSH certificate authority scales this far better than hand-editing files.

Rotation closes the loop. Plan to replace keys on a schedule, and immediately whenever a device is lost, a passphrase may have been seen, or someone with access leaves. Because revoking a key is simply removing its public half from authorized_keys, keys that are named and inventoried are dramatically easier to retire than anonymous ones you can no longer account for.

Where to store keys and passphrases

The private key file itself should stay on the device that uses it, protected by its passphrase and the operating system’s own file permissions — not synced around in plain cloud folders. But the passphrases that unlock those keys, along with recovery codes and the occasional key you genuinely must back up, do need a safe home, and a plain-text file or a notes app is not it.

An end-to-end encrypted password manager is the right place for those secrets: the passphrases, the recovery codes and any exported key material are encrypted before they leave your device and synced safely across the machines you own. It keeps the human-memorable part of SSH security out of plain sight, without the operational burden of running your own vault server.