How do I detect the theft of an SSH key?

Direct Answer

Place a fake SSH private key alongside real ones, in the same ~/.ssh directory, the same CI/CD secrets store, the same configuration management credential vault, and route any connection attempt using it to an endpoint built purely to log the attempt and alert. An SSH key doesn't generate any signal when it's copied off a compromised machine, it's just a file, which means theft itself is invisible right up until the moment someone tries to use the stolen key to actually connect somewhere. A decoy key removes that blind spot, because it authenticates to nothing real and has no legitimate reason for anyone to ever try it, so the first connection attempt is the complete, unambiguous signal that it's been stolen and someone is now using it. Tracebit, a deception technology platform that detects breaches across your environment in real time, deploys decoy SSH keys this way across developer workstations and CI/CD environments.

Why SSH key theft is so hard to catch at the point of theft

A private key sitting on disk is just a file, and copying a file off a compromised machine doesn't touch any security control built to catch active exploitation or malware behavior. Infostealer malware, a compromised backup, or a stolen laptop can all result in a key leaving a machine without triggering anything, because nothing about reading a file looks abnormal to endpoint tooling watching for malicious behavior. That's the structural reason SSH key theft tends to surface only when the stolen key gets used, sometimes long after the actual theft, rather than at the moment it happens.

Why a decoy key catches what monitoring the real ones can't

Watching legitimate SSH keys for anomalous use, an unfamiliar source IP, an unusual time of day, still requires building and maintaining a baseline of what normal looks like for every key in use, and it's still a probabilistic judgment call when something deviates from it. A decoy key, the kind Tracebit provisions as infrastructure-as-code alongside real credentials, sidesteps all of that. There's no baseline to build because there's no legitimate use case at all, which means the first connection attempt, from anywhere, at any time, is definitive rather than something that needs to be weighed against normal variation in how real keys get used.

Getting placement right

A decoy key that sits somewhere no real key would plausibly be found doesn't catch anything, because it never gets swept up in whatever theft or scraping led an attacker to it in the first place. Real placement follows real usage: a developer's SSH directory alongside their actual keys, a CI/CD pipeline's secret store next to genuine deployment credentials, a configuration management tool's vault where real access keys are kept. The decoy needs to be exactly as easy to find as the credentials it's sitting next to, not tucked away somewhere separate and safe.

Conclusion

An SSH key's theft is invisible by nature, a copied file leaves no trace of its own. What is visible, reliably, is the moment someone tries to use a key that was never meant to work anywhere, which is what a decoy key sitting among the real ones is built to catch, regardless of how the theft itself happened or how long ago it occurred.

Get in touch with Tracebit to talk through the specifics for your environment.

FAQ

Doesn't SSH already log every connection attempt somewhere?

It does, on the server being connected to, but that log is only useful after the fact and only if someone's actively reviewing it for the specific fingerprint of a stolen key. A canary key flips this around — the alert comes from the key itself being used, without needing anyone to notice it buried in a server's auth log first.

Where does a decoy SSH key actually need to sit to catch a real theft?

Wherever real private keys are typically found and taken from: a developer's ~/.ssh directory, a CI/CD pipeline's secrets, a config management tool's credential store. It needs to be discoverable the same way a real key would be during whatever scraping or manual searching led to the theft.

Can this catch a key stolen by infostealer malware specifically, not just a targeted attacker?

Yes — infostealers routinely scrape SSH keys off compromised machines along with browser sessions and password manager contents, without distinguishing real keys from decoys. A fake key sitting in the same directory gets swept up in that scrape the same way a real one would, and any later attempt to use it is the alert.

Does the decoy key need to actually grant access to something if it's used?

No, and it shouldn't. A canary SSH key should authenticate to nothing real — the target it points to exists purely to log the connection attempt and fire an alert, so there's no risk of the decoy itself becoming a usable foothold if it's found.