SSH key security

Topic: Security basics

Protect SSH private keys with passphrases and correct file permissions; use one key per purpose or environment; rotate and revoke keys when people leave or keys are compromised. Use this when hardening SSH access or responding to a key leak.

Intent: How-to

Quick answer

  • Private keys must be mode 600 and owned by the user; never world-readable. Use a passphrase so a stolen key file is not enough; use ssh-agent so you type the passphrase once per session.
  • Prefer one key per purpose (e.g. work vs personal, prod vs dev) so compromise of one does not affect others. Do not share private keys; each person has their own key and it is added to authorized_keys on servers.
  • Rotate keys when someone leaves or a key may be compromised; remove the old public key from all servers and authorized_keys files; issue a new key and deploy the new public key.

Prerequisites

Steps

  1. Protect the private key

    chmod 600 ~/.ssh/id_ed25519; chown user:user. Add a passphrase (ssh-keygen -p) so theft of the file is not sufficient. Use ssh-agent to avoid typing passphrase repeatedly.

  2. One key per purpose

    Use different keys for different roles or environments (e.g. id_ed25519_work, id_ed25519_personal). Configure ~/.ssh/config with IdentityFile per host so the right key is used.

  3. Deploy and revoke

    Add only the public key to servers (authorized_keys). When rotating or offboarding, remove the old public key from every server; add the new key; confirm the old key no longer works.

  4. Audit and monitor

    Periodically list who has which keys in authorized_keys on critical servers. Use audit or centralized config (e.g. LDAP, config management) so key removal is consistent.

Summary

Keep private keys 600 and passphrase-protected; use one key per purpose; rotate and revoke by removing public keys from all servers. Use this to harden SSH and respond to key compromise.

Prerequisites

Steps

Step 1: Protect the private key

chmod 600; add passphrase; use ssh-agent for convenience.

Step 2: One key per purpose

Use separate keys per role or environment; set IdentityFile in ~/.ssh/config.

Step 3: Deploy and revoke

Add only public keys to servers. On rotation or offboard, remove old public keys everywhere; add new; verify old key fails.

Step 4: Audit and monitor

Review authorized_keys on critical hosts; use centralized config so revocation is consistent.

Verification

Private keys are 600 and passphrase-protected; public keys are only on intended servers; revoked keys no longer work.

Troubleshooting

Key compromised — Revoke immediately (remove from all authorized_keys); issue new key and replace. Passphrase forgotten — Generate a new key pair and replace the public key on servers; old key is unusable.

Next steps

Continue to