Leaked SSH / RSA Private Key: what to do in the first hour

• A whole ~/.ssh directory in a repository. Often via a dotfiles repo, or a git add . in the home folder.
• Keys baked into Docker images and CI. A COPY id_rsa or an ARG in a Dockerfile (they remain in image layers), or a deploy key pasted into a workflow file instead of the secrets store.
• Backups and archives. A zipped project folder, a backup of a laptop or server pushed to a public repository or bucket.
• Test fixtures and sample configs. A real key used to “make the example work” in a tests/ or examples/ folder.
• Pasted for help. In an issue, a chat or a forum post, while asking why authentication fails.

1. Identify the key and what trusts it. Work out the public key that goes with it. If you still have the private file, ssh-keygen -y -f <file> prints the public key and ssh-keygen -l -f <file> prints its fingerprint. Then list where it might be installed: servers (~/.ssh/authorized_keys of each user, and /root/.ssh/authorized_keys), GitHub and GitLab (account SSH keys and repository deploy keys), cloud key pairs, CI/CD settings, Git hosting for other teams, and any bastion hosts.
2. Remove the public key from every one of those places. On servers, delete its line from authorized_keys. On GitHub, open Settings → SSH and GPG keys, and repository Settings → Deploy keys. Do this before you generate a replacement, so there is no window where the leaked key still works. Deleting a key pair in a cloud console does not remove it from instances that already have it, so check the instances too.
3. Generate a new pair, protected by a passphrase. ssh-keygen -t ed25519 -C "<purpose>" creates one, and the passphrase prompt protects the file if it leaks again. Use a separate key per purpose (one per server group, one for CI) so a single leak does not unlock everything.
4. Look for logins made with the old key. On Linux servers, sshd logs accepted public-key logins with the key fingerprint, in /var/log/auth.log or via journalctl -u ssh (or sshd). Search for the fingerprint from step 1. Also look at last for unfamiliar sources.
5. Look for persistence on any machine it could reach. An attacker who got in often adds their own key to authorized_keys, creates a user, adds a cron job or a systemd unit. If you find any of these, treat the machine as compromised and rebuild it rather than clean it.
6. Rotate what lived on those machines. Environment variables, config files and anything else readable by the login user.
7. Then clean the repository: remove the file, add it to .gitignore, and rewrite history if you want to. See I accidentally pushed an API key to GitHub.

Not sure what else leaked from the same repository? Run a free scan.

A key has no issuer, so you revoke it by removing trust. For SSH, that means deleting the public key from each authorized_keys file, from your Git hosting account and deploy keys, and from any CI or cloud setting that holds it; there is no central list to query. The fingerprint from step 1 is your search term. If the key was a server host key (in /etc/ssh/ssh_host_*_key) rather than a login key, regenerate the host keys on that server and let your users know their clients will warn about the change.

LeakWatch matches a block that starts with a BEGIN … PRIVATE KEY marker and ends with the matching END marker. It does not check this type live, and it could not: a private key is proof of possession, not a token you can send to a server and ask “is this still active?”, and testing it would mean using someone else’s key to sign in. Instead LeakWatch analyzes the key itself, offline: whether it is a real key rather than a template or a truncated block, and whether it is protected by a passphrase. It can tell you the key is exposed, not whether it still opens anything. Assume it does until you have removed it everywhere.