Ever try to revoke SSH access across a thousand servers? It sucks. Here’s a better way.

Technical Briefing | 9/16/2026

Remember that feeling when someone leaves the company, and you’ve got to prune their SSH public key from a few dozen, or maybe a few hundred, authorized_keys files scattered across your production estate? Yeah, it’s a grind. And if you miss one, that’s an orphaned key just sitting there, potentially giving unauthorized access for who knows how long. This isn’t just an annoyance; it’s a gaping security hole, especially when you’re trying to build a sensible Zero Trust model. I’ve seen this silently fail on teams trying to be diligent, only to find old keys floating around months later.

The Problem with Public Key Sprawl and Long-Lived Access

Most of us start with ssh-copy-id or just slapping keys into ~/.ssh/authorized_keys. It works, right? Until you’re at scale. Managing these keys becomes a full-time job for bigger environments. Auditing who has access to what, when, and for how long? Nearly impossible without serious tooling, and even then, it’s often an after-the-fact discovery. But the bigger issue, one that truly bit me in prod once, is how long these keys live. A key that’s valid for years for unrestricted access to critical systems? That’s just asking for trouble. One compromised laptop, and you’ve got a whole new set of problems on your hands because that key might give broad access for the foreseeable future.

SSH Certificates: A CA-Backed Breath of Fresh Air for Access Control

Here’s where SSH certificates step in and genuinely simplify our access management. Instead of individual user keys being trusted directly by each server, you introduce a Certificate Authority (CA). This CA signs your user’s public keys, issuing a certificate that’s only valid for a specific period, for specific users (or ‘principals’), and even for specific servers or groups of servers. The server trusts the CA, not each individual user key. It’s a fundamental shift, moving from decentralized trust to a centralized, revocable model. And revocation is instant at the CA level, making cleanup way faster and more reliable than hunting down hundreds of authorized_keys files.

# This goes into /etc/ssh/sshd_config to trust your CA for user authentication
TrustedUserCAKeys /etc/ssh/trusted_user_cas.pub


# Optional: Further restrict principals allowed for users connecting
# For example, if a user's cert has the principal 'admin', and they connect
# to a server configured like this, sshd looks for /etc/ssh/authorized_principals/admin
# AuthorizedPrincipalsFile /etc/ssh/authorized_principals/%u


# Don't forget to reload sshd after making changes to pick them up
systemctl reload sshd

• Centralized trust: No more spreading user public keys across hundreds of authorized_keys files. You manage a few CA public keys on your servers, that’s it.
• Ephemeral access: Certificates can be valid for an hour, a day, or whatever policy you need. Temporary access expires automatically; no manual cleanup needed.
• Granular control: Embed principals (like dev-team, db-readonly) and even source IP restrictions directly into the cert. Your sshd config can then enforce these.
• Auditing: Your CA logs every certificate issued, making it dead simple to see who got access, when, and for how long. That’s a huge win for compliance.
• Instant revocation: Revoke a user’s cert or, even better, compromise a CA and you just replace its public key on the hosts. The old certificates are instantly invalid.

This isn’t just about security; it’s about making your life as an ops engineer sane. Imagine not having to chase down authorized_keys files every time someone leaves. Or needing to grant temporary access for an incident and knowing it’ll expire automatically. Setting up an SSH CA might sound like a big lift, but tools like Smallstep step-ca or even an OpenSSL-based setup are much simpler than they used to be. You’re building a foundation for truly ephemeral, least-privilege remote access, which is the heart of any effective Zero Trust architecture.