We audited every SSH connection to production for a month. Here's what we found.

Coddy — Fri, 24 Jul 2026 14:21:47 +0000

After the ex-employee key incident, I stopped trusting my own assumptions about who was actually connecting to what. So for one month, I logged every SSH session across three environments: a 6-person startup, a 40-person mid-size company, and my own infrastructure.

The numbers were worse than I expected.

23% of connections came from credentials nobody could immediately identify.

Not malicious, mostly. Old CI/CD service keys still hanging around. A contractor's access that IT thought was revoked. One senior engineer connecting through a personal laptop key he'd generated two jobs ago and never removed from the authorized_keys file.

The average time between "this person left the team" and "their SSH access was actually cut" was 11 days.

At the 40-person company, offboarding meant filing a ticket, waiting for infra to manually SSH into each box, and removing the key by hand. Eleven days is eleven days of a former employee, or worse, whoever now controls their laptop or email, having standing access to production.

Nobody could answer "who connected to the payments database last week" without grepping raw auth logs across a dozen hosts.

Not because they didn't care. Because the tooling made it genuinely hard. Bash history is local and unreliable. Centralized logging existed but nobody had built the query for "SSH sessions grouped by host and user" because nobody had needed it until they suddenly did, mid-incident.

Here's what actually fixed it, in order of impact:

1. One source of truth for who has access to what. Not a spreadsheet. Not "ask in the #infra channel." A system where access is a first-class object you can list, not a side effect of someone having a key file somewhere.

2. Revocation as a single action, not a per-host chore. If cutting access takes more than one click, it will eventually take more than one day. Every day past zero is risk you're carrying for no reason.

3. An audit log that answers the question before someone asks it. Not "technically the data exists in syslog somewhere." A log you'd actually query during an incident, at 2am, without needing to remember which host has which retention policy.

None of this is exotic. It's the same access-control discipline every team already applies to production databases and cloud consoles. SSH just tends to be the one thing that's still running on trust and tribal memory, because it's the layer underneath everything else and nobody wants to touch it.

I ended up building this into SecurSSH after hitting the same wall repeatedly, team vaults instead of shared keys, role-based access that revokes instantly, and an audit log that's actually queryable. Not the point of this post though, the audit itself is worth doing regardless of what tool you use afterward.

If you run the same kind of audit on your own infra, even informally for a week, I'd genuinely like to know what you find. My guess is the offboarding gap is universal.

The day I found an ex-employee's SSH key still active in production — 18 months later

Coddy — Fri, 03 Jul 2026 10:39:56 +0000

It was a routine audit.

I was going through our authorized_keys files across production servers — something I do every few months, mostly out of paranoia.

Then I saw it.

A key belonging to a developer who had left the company a year and a half ago.

Not a contractor. Not a freelancer.A full-time engineer who had access to everything.Database servers. API endpoints. The works.

He had probably forgotten about it.We had definitely forgotten about it.

This is not a rare story

Ask any sysadmin and they will tell you a version of this. The details change.
The outcome doesn't.

The problem is structural.

SSH was built for individual access.
There is no native concept of a team,a role, or an expiration date.

authorized_keys files multiply silently
across servers. Keys get copied without anyone noticing. Offboarding is manual —and manual means missed.

What went wrong — and why it keeps happening

1. No single source of truth

Every developer manages their own ~/.ssh config.Nobody has a complete picture of who has access to what across the entire infrastructure.

2. Key sprawl is invisible

There is no standard way to audit SSH access.
Keys get copied. Servers get cloned.
The surface area grows quietly.

3. Offboarding is an afterthought

Removing someone from Slack, email, and GitHub takes 10 minutes. SSH? That's on someone's to-do list. It stays there.

4. Rotation is too painful to do

Rotating SSH keys properly means updating every authorized_keys on every server.
In practice, most teams never rotate.
The key that was "temporary" in 2023 is still there in 2026.

What I changed after that day

Centralized every SSH credential in one encrypted place
Assigned access per role — not per individual
Set up an audit trail for every connection
Made offboarding a one-click operation

The tools to do this properly exist now.We just don't talk about them enough.

The question nobody asks until it's too late

How many active SSH keys does your team have right now across all servers?

Not the ones you know about.
All of them.

If you can't answer that question instantly,you have the same problem we had.

Has this ever happened to your team?
How do you handle SSH access management?