The decision to move SSH access onto certificates is the easy part. The architecture that makes it work in production is where most projects stall. An SSH certificate authority is not a single component you drop in; it is a small system with an identity integration, a signing service, a set of host configurations, an audit pipeline, and a revocation and rotation story that has to hold up under pressure.
This post lays out a working architecture for an SSH CA paired with a bastion host. The goal is a design where a user authenticates through your identity provider, receives a short-lived certificate scoped to exactly what they are allowed to reach, connects through a bastion that records the session, and never manages a long-lived private key as their access credential. Hosts prove their own identity so the trust-on-first-use prompt disappears. Access ends when issuance stops, and the CA key itself can be rotated without a fleet-wide outage.
Reactive vs. Proactive Certificate Management
Score comparison across key operational metrics (higher = better)
🔥 Reactive
4-24hr MTTD · $134K/year · 6+ outages · Burnout
✓ Proactive
<15min MTTD · $15K/year · 0 outages · Planned
The Components and How They Fit
An SSH CA architecture has four moving parts, and keeping their responsibilities separate is what keeps the design maintainable.
The user CA and the host CA
Run two separate certificate authorities, not one. The user CA signs certificates that authenticate people and automation to hosts. The host CA signs certificates that authenticate hosts to clients. Separating them means a compromise or rotation of one does not entangle the other, and the trust relationships stay easy to reason about: hosts trust the user CA to vouch for users, and clients trust the host CA to vouch for hosts.
The signing service
The signing service is the component that holds the CA private keys and issues certificates in response to authenticated requests. It must authenticate the requester against your identity provider before signing anything, embed the correct principals and validity window, and log every issuance. The CA private keys should live in an HSM or a cloud KMS that performs the signing operation without ever exposing the key material to the service process.
The bastion host
The bastion, or jump host, is the single controlled entry point into a network segment. Users connect to the bastion with their certificate, and from the bastion they reach internal hosts. The bastion is where you concentrate session recording, connection logging, and network-level controls, because it is the chokepoint every session passes through.
The identity provider
The identity provider, through SSO or OIDC, is the source of truth for who a person is and what groups they belong to. The signing service translates that identity into certificate principals. This is the link that makes offboarding instant: remove the person from the identity provider, and the signing service stops issuing them certificates.
Short-Lived User Certificates Tied to Identity
The core of the design is that a user never holds a durable access credential. They authenticate to the signing service through the identity provider, and in exchange they receive a certificate that is valid for hours, not forever.
The issuance flow
When a user wants access, their client generates an ephemeral keypair locally, authenticates to the signing service via OIDC, and submits the public key to be signed. The signing service verifies the identity, maps the user’s group memberships to principals, sets a short validity window, and returns a signed certificate. The user’s private key never leaves their machine, and the certificate it is bound to expires the same day.
# Conceptual issuance step: client obtains a short-lived cert after SSO
ssh-keygen -t ed25519 -f ~/.ssh/id_session -N ""
# client authenticates via OIDC, submits id_session.pub to the signing service,
# receives id_session-cert.pub signed by the user CA with principals and a TTL
ssh -i ~/.ssh/id_session -i ~/.ssh/id_session-cert.pub user@bastion.example.comMapping identity to principals
Principals are how you express authorization. A user in the “platform” group receives a certificate carrying the “platform” principal; a user in “dba” receives “dba”. Hosts are configured to accept only the principals appropriate to their role, so the certificate itself declares what it may do and the host enforces it.
# /etc/ssh/sshd_config on a database host
TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u# /etc/ssh/auth_principals/postgres on the database host
# only certificates carrying the dba principal may log in as the postgres account
dbaThis decouples authorization from per-host key files. To change what a group can reach, you change the principal policy at issuance and the principal acceptance on hosts, not a scattered set of authorized_keys entries.
Host Certificates to Kill TOFU
The second half of the trust problem is proving host identity. Without host certificates, every user is asked to accept an unknown fingerprint on first connection, and most accept it without checking. An attacker who can position an impostor host benefits directly from that habit.
Host certificates remove the prompt entirely. Each host is issued a certificate signed by the host CA, and clients are configured to trust the host CA. When a client connects, the host presents its certificate, the client validates it against the CA, and because the CA vouched for the host there is no unknown fingerprint to accept.
# sshd_config on each host, presenting its host certificate
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
HostKey /etc/ssh/ssh_host_ed25519_key# Client-side known_hosts, trusting the host CA for the internal domain
@cert-authority *.internal.example.com ssh-ed25519 AAAA...hostCApubWith this in place, a user connecting to a host for the first time connects silently and securely, and a host that cannot present a valid certificate is rejected rather than accepted on faith.
The Bastion as the Controlled Chokepoint
The bastion host is where you concentrate the controls that are awkward to spread across every internal host. Users connect to the bastion with their short-lived certificate, and the bastion is configured as the single ingress to the protected segment.
Why route through a bastion at all
A bastion gives you one place to record sessions, one place to enforce network segmentation, and one place to observe every connection into the environment. Internal hosts can be configured to accept connections only from the bastion, which shrinks the attack surface to a single hardened entry point rather than every host being individually reachable.
Connecting through the bastion with certificates
The client uses the bastion as a jump host, and the same certificate authenticates both the hop to the bastion and the hop to the internal target, because both hosts trust the same user CA.
# ~/.ssh/config on the client
Host bastion
HostName bastion.example.com
User jdoe
IdentityFile ~/.ssh/id_session
CertificateFile ~/.ssh/id_session-cert.pub
Host 10.*.*.*
ProxyJump bastion
IdentityFile ~/.ssh/id_session
CertificateFile ~/.ssh/id_session-cert.pubThe user runs one command to reach an internal host, the connection transits the bastion, and the bastion records it.
Audit, Revocation, and CA Rotation
A certificate architecture is only as trustworthy as its ability to answer questions after the fact and to recover from a compromised credential.
Audit from issuance, not just from hosts
The signing service log is the authoritative record of access. Every certificate issued is a logged event: who requested it, what principals it carried, when it was issued, and when it expires. Combined with bastion session logs, this gives you a complete picture: the issuance log shows who was granted access and the bastion log shows what they did with it. Unlike raw keys, where access is invisible until you scan a host, certificate access is observable at the moment it is granted.
Revocation and why short lifetimes reduce the need
Revocation in SSH is handled through a key revocation list referenced by the RevokedKeys directive, which lets a host reject specific certificates before expiry. It works, but it requires distributing the revocation list to hosts, which is operational overhead. The better primary control is short lifetimes: a certificate valid for a few hours limits the window during which revocation even matters. You keep the revocation list for the rare case where you must cut off a still-valid certificate immediately, and you rely on short TTLs for the common case.
# sshd_config, rejecting any certificate listed as revoked
RevokedKeys /etc/ssh/revoked_keysRotating the CA key without a fleet-wide outage
The CA key will eventually need rotation, whether on a schedule or in response to suspected compromise. Done naively, rotating it is a fleet-wide outage, because every host trusts the old CA and none trust the new one. The safe path is to run both CAs in parallel during the transition: add the new CA public key to the trust configuration on every host while the old one is still trusted, cut issuance over to the new CA, confirm new certificates work across the fleet, then remove trust in the old CA. Because hosts can trust multiple CA keys at once, the rotation is a rolling change rather than a hard cutover.
# TrustedUserCAKeys can reference a file containing multiple CA public keys
# during rotation, both old and new CA keys are listed; old is removed after cutover
TrustedUserCAKeys /etc/ssh/user_ca_keys.pubSequencing the Rollout
Build the architecture in an order that keeps the existing access path working until the new one is proven.
- Stand up the user CA and host CA with keys in an HSM or KMS, and build the signing service with identity integration.
- Issue host certificates and configure client trust for the host CA, removing TOFU for a pilot segment.
- Integrate issuance with the identity provider and move a pilot group of users to short-lived certificates, with legacy keys still in place as a fallback.
- Route the pilot through the bastion and confirm issuance logs and session logs give you the audit picture you need.
- Expand to the full fleet, then drain legacy authorized_keys once certificate access is proven for each population.
Each step is reversible until the legacy keys are removed, which is what makes the rollout safe to run against a live environment.
FAQ
Q: Why run separate user and host CAs instead of one? Separation keeps the trust relationships clean and limits blast radius. Hosts trust the user CA to vouch for people; clients trust the host CA to vouch for hosts. If you ever need to rotate or respond to a compromise of one, you do not disturb the other, and nobody has to reason about a single key that does two unrelated jobs.
Q: Where should the CA private keys live? In an HSM or a cloud KMS that performs signing without exposing the key material to the signing service process. The CA key can mint access to everything that trusts it, so it is the highest-value secret in the architecture. Keeping it in hardware with an access log and strict controls is the baseline, not an enhancement.
Q: Do I still need a bastion if every host has certificate auth? You do not strictly need one, but it is where concentrating session recording, connection logging, and network segmentation is cheapest. A single hardened chokepoint is easier to observe and control than spreading those controls across every internal host. Many designs keep the bastion specifically for that reason even after certificates are in place.
Q: How do short lifetimes interact with long-running automation? Automation requests certificates the same way users do, through an authenticated flow, but on a schedule that refreshes before expiry. The goal is that no component holds a permanent credential. For jobs that run continuously, the signing service issues a fresh short-lived certificate ahead of each expiry, so the automation always has a valid, time-boxed credential and never a durable key.
Q: What happens during CA rotation if I get the order wrong? If you cut issuance to the new CA before every host trusts it, certificates signed by the new CA are rejected and users lose access. The safe order is to add trust for the new CA across the whole fleet first, confirm it, then move issuance, then remove the old CA. Because hosts can trust several CA keys at once, keeping both trusted during the transition avoids any outage.
About QCecuring
QCecuring helps enterprises design and operate SSH certificate authorities that tie access to identity, prove host authenticity, and keep audit and rotation under control. Our platform runs the issuance path against your identity provider, protects the CA keys in hardware, and makes CA rotation a rolling change rather than a fleet-wide outage.
Design your SSH CA and bastion architecture with us
Tags: SSH Key Management, PKI Automation, Certificate Authority, Bastion Host, Jump Host, OIDC, SSO, Short-Lived Certificates, Host Certificates, Principals, Audit, CA Rotation, Zero Trust