Use SSH certificates with step-ca
Managing SSH keys at scale gets messy fast. Teams accumulate long-lived keys, offboarding is slow, and nobody loves editing authorized_keys across fleets. step-ca gives operators a cleaner model: issue short-lived SSH certificates from a private CA, tie access to identity, and keep OpenSSH workflows intact.
What is step-ca?
step-ca is an open-source certificate authority from Smallstep. It supports X.509 and SSH certificates, ACME, and automated enrollment flows that fit modern infrastructure. For SSH, it can issue certificates for people and hosts, which lets you replace scattered static keys with centrally managed, time-bound credentials.
That matters for SRE teams because access becomes easier to reason about. Instead of trusting hundreds of raw keys forever, you trust a CA and define who can get a certificate, for what role, and for how long.
Key Features
- Issues SSH user and host certificates from one private CA
- Supports short-lived credentials to reduce key sprawl and stale access
- Works with standard OpenSSH clients and servers
- Can exchange OIDC identity tokens for SSH certificates
- Also handles internal TLS certificates, which is useful for platform teams standardizing trust
Installation
On Debian or Ubuntu, Smallstep documents installation like this:
apt-get update && apt-get install -y --no-install-recommends curl gpg ca-certificates
curl -fsSL https://packages.smallstep.com/keys/apt/repo-signing-key.gpg -o /etc/apt/keyrings/smallstep.asc
cat << 'STEPREPO' > /etc/apt/sources.list.d/smallstep.sources
Types: deb
URIs: https://packages.smallstep.com/stable/debian
Suites: debs
Components: main
Signed-By: /etc/apt/keyrings/smallstep.asc
STEPREPO
apt-get update && apt-get -y install step-cli step-ca
For macOS, the quick path is:
brew install step
Usage
A common pattern is to initialize step-ca, configure SSH certificate templates, and let engineers request short-lived certificates with the step CLI. At a high level, the flow looks like this:
step ca init
step ssh login [email protected]
ssh [email protected]
Once your hosts trust the SSH CA, certificates become the access layer. You can issue user certs for a few hours, map principals to roles, and stop worrying about forgotten public keys that never expire.
Operational Tips
Keep certificate lifetimes short. A few hours is often enough for human access. Use host certificates too, so engineers can verify they are connecting to trusted machines instead of blindly accepting host keys. If your organization already uses Google Workspace, Okta, or another OIDC provider, connect identity to issuance so access follows the same lifecycle as employment.
For production rollouts, start with a small admin group, audit SSH principals carefully, and add logging around certificate issuance. This gives you a clear trail for who accessed what and when.
Conclusion
SSH certificates solve one of the most annoying access problems in infrastructure: long-lived keys spread across too many systems. step-ca makes the model practical for real teams by combining an SSH CA, identity-aware issuance, and familiar OpenSSH tooling.
If you want fewer manual access tasks and faster incident response, Akmatori helps SRE teams automate repetitive operational work. For reliable global compute to run your platform, check out Gcore.