How to rotate SSH keys when someone leaves

Someone leaving means two separate SSH jobs. Their own key needs no reissue at all: the private half was theirs, so remove their public key from every authorized_keys file and every service that trusts it. A shared key whose private half they could read, such as a deploy key or a team's server key, needs a real reissue: generate a new pair, add the new public key next to the old one on every host, move each client to the new private key, and then delete the old public key. An authorized_keys file holds one key per line, so both keys work during the switch and nobody gets locked out (sshd manual).

Crunu doesn't log in to your servers or edit authorized_keys. It keeps shared private keys as files in an environment, shows who received which version, and writes the new key to the machines that need it.

Where a public key is trusted

sshd reads public keys from the files named by AuthorizedKeysFile, by default .ssh/authorized_keys and .ssh/authorized_keys2 in the user's home directory (sshd_config). Every line is one key with an optional options field in front. The options are your scope controls, and a reissue is a good time to add them:

• from= limits the key to hosts or addresses, including CIDR ranges.
• command= forces one command whenever the key is used and ignores what the client asked for.
• restrict turns off port, agent and X11 forwarding, PTY allocation and ~/.ssh/rc, and will include future restrictions too.
• expiry-time= sets a date after which the key is no longer accepted.

Servers aren't the only places. Code hosting stores deploy keys, cloud providers inject keys into new machines, and removing a person from a cloud team doesn't necessarily remove their keys from machines already running. The pages on GitHub deploy keys and DigitalOcean cover two common cases.

Reissue a shared key without downtime

ssh-keygen -t ed25519 -C "deploy payments-api 2026-10" -f ./deploy_ed25519
crunu pull --env payments-api/production
ssh -i ~/deploy/deploy_ed25519 deploy@api-prod-1 true

crunu pull writes files with mode 0600 and refuses paths inside ~/.ssh/ unless you pass --allow-path for that run, so either keep deploy keys outside ~/.ssh/, as in this example, or allow the path explicitly.

Make the removal stick

Deleting a line works until someone pastes it back. RevokedKeys in sshd_config names a file of keys that sshd always refuses, written either as plain public keys, one per line, or as a key revocation list made with ssh-keygen -k. Two warnings from the manual: if that file isn't readable, public key authentication is refused for every user, and because sshd may read it on each attempt, replace it atomically rather than editing it in place.

ssh-keygen -k -f /etc/ssh/revoked_keys.krl ./old_deploy_ed25519.pub

Removing a key affects the next authentication. A session that is already open was authenticated before the change, so end the departing person's open sessions separately.

Keys that expire on their own

Plain key pairs never expire, which is why old keys pile up. OpenSSH certificates are the alternative. A host trusts a certificate authority listed in TrustedUserCAKeys, and you sign each user's key with ssh-keygen -s, using -V to set a validity interval (ssh-keygen). Outside that interval the certificate isn't valid, so a departure ends at the next expiry even if nobody edits a single server. Without -V, a certificate is valid from the Unix epoch to the distant future, and a certificate without principals isn't accepted through TrustedUserCAKeys.

When to reissue SSH keys

• A departure. Remove their personal keys everywhere, reissue every shared key they could read, and end their sessions. In Crunu, removing the person produces a reissue checklist of the files they received, such as a deploy key, by path.
• A leak. Remove the old public key and add it to the revoked keys file first, then distribute the new pair.
• A schedule. Shared keys have no built-in end date, so reissue them on a calendar or move to certificates.

What to rotate when a developer leaves puts SSH in the context of the whole departure, and the offboarding checklist builds the list for your stack.