Exposed Private Key (RSA / SSH / EC)? Here's how to detect and rotate it

A private key is the secret half of a keypair — the block that starts with -----BEGIN … PRIVATE KEY-----. It might be an SSH key that logs into your servers, a TLS key that terminates HTTPS for your domain, or a signing key that proves a token or artifact really came from you. The public half is meant to be shared; the private half must never leave your control. If it leaks, anyone holding it can act as you.

What an attacker can do with a leaked Private Key (RSA / SSH / EC)

• Logs into any server, VM, or Git host that trusts the matching public key — full shell access as you.
• Decrypts intercepted HTTPS/TLS traffic or impersonates your site if it's the private key behind your cert.
• Forges signatures — signs tokens, releases, packages, or JWTs that your systems will trust as genuine.
• Uses that foothold to move laterally, plant backdoors in authorized_keys, and reach other machines and secrets.

How Private Key (RSA / SSH / EC)s get exposed

• The id_rsa / id_ed25519 file gets committed to a repo instead of just its .pub public half.
• A TLS .key or .pem is baked into a Docker image, a deploy artifact, or a public bucket.
• A CI/CD deploy key is pasted into a plaintext config or a build log instead of an encrypted secret.
• The key is shared over Slack, email, or an AI chat to ‘help debug’, then never rotated.

How to rotate a leaked Private Key (RSA / SSH / EC)

1. Generate a brand-new keypair — for SSH run ssh-keygen -t ed25519 -C "you@example.com" to a new filename; for TLS generate a fresh key and CSR; for a signing key mint a new one in your tool.
2. Add the NEW public key everywhere the old one was trusted — append it to ~/.ssh/authorized_keys on each server, add it as a new GitHub/GitLab deploy key, or install the reissued cert — and keep the old one in place for now so you don't lock yourself out.
3. Test that the new key works (ssh in with it, or verify the new cert serves) before you touch the old one.
4. Now remove every trace of the old key — delete its line from authorized_keys, delete the old deploy key in your Git host's settings, and delete the leaked key file locally.
5. For a TLS key, reissue the certificate from your CA and REVOKE the old cert so the leaked key can't be used even if someone kept it.
6. Audit auth and access logs — SSH logins, Git clone events, cert usage — for any sessions from unfamiliar IPs while the key was exposed.