You Can't Leak a Key You Never Held

SSH key management is an in-house project you never meant to start. Here's how to get out of it.

It starts innocently. A new engineer joins, and getting them SSH access means generating a keypair, getting the public key onto the right hosts, and hoping you got all of them. Then someone leaves, and now you're grepping across the fleet trying to find every place their key landed. Somewhere in between, a key that should have been rotated two years ago is still sitting in an authorized_keys file on a box nobody's logged into since. None of this is hard. It's just endless, and it's become one of the most consistent time sinks on your plate.

Nobody decided to build this. You have one anyway.

SSH key management isn't a project you scoped. It accreted. A rotation cron someone wrote and left behind, authorized_keys files scattered across every host, keys tucked into CI variables, keys sitting in ~/.ssh on laptops you don't control. Every one of those was a reasonable call in the moment. The sum is a homegrown system for issuing, distributing, and tracking credentials, and you're maintaining it for free, in the margins, because it was never actually anyone's job.

That's what makes it a build-vs-buy question, even though nobody framed it that way. It all runs on the honor system: it works until it doesn't, and when it doesn't, it's usually because someone left, or something leaked, or an auditor asked a question nobody could answer quickly.

The wheels you're reinventing

Strip it down and you're hand-rolling four things that are genuinely solved problems everywhere else:

Distribution. Getting the right public keys onto the right hosts, and keeping that true as the fleet changes. Every new host, every rebuild, every autoscaling event is a chance for the map to drift.

Rotation. Keys that should rotate but don't, because rotating means touching every host they live on, so in practice they just... don't. The average SSH key in a mature environment is older than most people would admit.

Revocation. The one that actually keeps people up at night. Someone leaves, or a laptop walks off, and now you're grepping the fleet for a key, hoping the list of hosts you're checking is complete. You will never be fully sure it was.

Sprawl. authorized_keys as an append-only file nobody prunes. Keys with no owner. Keys that outlived the person they belonged to. Access that accumulates because removing it is harder than adding it.

None of these are hard problems in isolation. They're just constant, and they're exactly the kind of undifferentiated work that eats platform-team hours without ever showing up as a feature you shipped. This is the wheel. You've been re-carving it for years.

The real problem isn't the effort. It's that the key exists at all.

The cost here stops being your time and becomes your exposure.. Every key you generate and distribute has to live somewhere a person can reach it. It's in ~/.ssh on a laptop. It's in a CI secret. It's pasted into a script, or sitting in an env var, or, on a bad day, committed to a repo by someone in a hurry. That's your attack surface, and it's bigger than you think, because you've been counting keys instead of counting the places each key can leak from.

The Verizon Data Breach Investigations Report analyzes tens of thousands of real breaches each year and reports how attackers actually got in. The finding that should matter to anyone holding an SSH key: stolen credentials were the initial access vector in 22% of breaches, and 88% of basic web application attacks involved stolen credentials.. Not clever zero-days. Not nation-state exploits. A credential that was sitting somewhere it could be taken.

Stolen credentials were the initial access vector in 22% of breaches; 88% of attacks against web applications involved stolen credentials.

Verizon 2025 Data Breach Investigations Report

And a stolen key is rarely just one machine. SSH is how people move between hosts, so a key that opens one box is often a key that opens the next, and the one after that. This is lateral movement, and it's the objective after an attacker gets in: turn one foothold into many, quietly, using credentials that are supposed to be there. A standing SSH key is perfect for it, and it looks exactly like legitimate use, because technically it is. A single stolen key can travel a long way before anyone notices. That's the real danger.

So the real question isn't how do I manage all these keys better. It's why is the key somewhere a human can reach it in the first place.

Inject the credential where the resource lives. The developer never holds the key.

Flip the model. Instead of distributing keys to people and hoping they hold them safely, the credential gets injected into the connection at the resource, pulled just in time, only for the life of that session.

The developer authenticates as themselves through your existing identity provider and gets connected. That's StrongDM sitting between the identity provider and the resource: it verifies who you are, decides whether you're allowed, and hands the session the credential. None of that complexity went away. Someone on your platform or IT team wires it up once, centrally, and from then on the hard part still exists, it just stopped being yours.

The important part: this holds regardless of where the key lives. Whether your credentials sit in AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault, or somewhere else entirely, the injection happens at the connection, not on the developer's laptop. You're not moving your secrets. You're removing the step where a human ends up holding them.

And this is what takes lateral movement off the table. When every session is authorized at connect time and tied to a real identity, and the credential only exists for the life of that session, a key stolen off a laptop opens nothing, because there's no key on the laptop to steal. Even connecting requires being you, right now, not just holding something you took. The standing credential that made a stolen key so dangerous simply isn't there anymore.

You can't leak a key you never held. That's not a slogan, it's the whole mechanism.

What you get back

You didn't want to be in the SSH key management business. So stop being in it.

The keygen ritual goes away. The distribution scripts go away. The rotation cron that everyone's afraid to touch goes away. And revocation, the one that used to mean grepping the fleet at 6pm on someone's last day, becomes turning off a person, once, and being done. Access is tied to identity, so when the identity is gone, the access is gone, everywhere, at the same time.

You also get things you never got around to building: every session tied to a real human, recorded, and available when an auditor or an incident asks who did what, where, and when. Not because you built a logging pipeline, but because it comes with connecting this way instead of the old way.

Want to see it work? The short demo below walks a real SSH session from request to recorded audit, the private key sitting in a vault the whole time, injected at connect, never touching a laptop.