Why you need an SSH Certificate Authority instead of static keys
A private key copied into a backup, onto a second laptop, or into a build configuration stops being a secret—but it keeps working. Long-lived SSH keys live for years: they are issued to a contractor for the duration of a project and revoked by manually going through the fleet.
By the time you need to prove who has access, neither operations nor security has an up-to-date list.
An SSH Certificate Authority removes the root cause: instead of a long-lived key, an engineer receives a short-lived certificate signed by the CA for a specific role.
Servers retain only the CA's public key, the private key never leaves the vault, and validity period and set of permissions are set in the certificate, not on the host.
SSH access management moves to a single point: issuance, lifetime, revocation. Key inventory turns into a list of issued certificates with owner and time, rather than a census of files across the entire fleet. Access audit relies on one log: who, when, and under which role was granted access.
Revocation stops being a manual operation. Issuance stops, and an already issued certificate expires on its own after a specified period—from several minutes to a shift.
A copy left on someone else's machine is useless by then: it has the CA's signature, but it is no longer valid.
Below we break down how to set this up: where to place the CA, how to connect it to current authentication, and what to do with keys that have already spread.
What centralized issuance of access certificates provides
Centralized issuance is built on a single trusted certificate authority key: sshd on each host reads it from TrustedUserCAKeys, and access is granted by a certificate signed by this CA.
Personal public keys in authorized_keys stop being a management point—they simply no longer remain on hosts, and the user's role is set by the principals field in the certificate. An engineer gains access with the same familiar command; only the source of trust changes.
Certificate lifetime becomes an access parameter. For automation and service tasks, we issue it for minutes; for manual on-call duty, for a work shift; and once the window expires, access closes by itself, without anyone's involvement.
The window shrinks from “until someone remembers” to a measurable interval, and this interval is the same for all hosts because it is set in one place, not in the configuration of each machine.
Access revocation stops being a project. It is enough to stop issuing new certificates for a role or person, and invalidate active ones via a revocation list—this takes minutes, not going through the host fleet and editing keys.
Upon termination or a role change, the access window does not stretch until the next access review; it closes the same day.
This eliminates an entire class of failures: “forgot to remove the key.” There is no one to forget—there is nothing to remove, because there are no permanent keys on hosts, and an issued certificate expires on schedule.
Legacy is also addressed separately, when the same key sits in a shared folder and passes between contractors and teams for years: such a key simply fails verification.
The connection log becomes complete and unambiguous. The host log shows the certificate serial number, the set of principals, and the certificate authority fingerprint, while the issuance log shows to whom, for which role, and for what period it was issued.
The two records are linked by number, so the question “who and when accessed this host” has an answer without manually reconciling access tables.
Methods of issuing SSH access: comparison of options
There are three options, and they differ not by tool but by the point where the access decision is made: on the host itself, in the certificate authority, or both at once. The practical criterion is one—how quickly access is closed for an engineer who left or lost a laptop.
Everything else—issuance convenience, access lifetime, audit completeness—is a consequence of the chosen point. Below is a comparison along two axes: when the option is appropriate and what the team pays for it.
| Option | When it fits | Limitations |
|---|---|---|
Static keys in authorized_keys |
Small host fleet, one or two administrators, access composition changes rarely | Revocation is manual editing on every host; the key has no expiration; a copy of the file bypasses control; audit only via login logs |
| Certificates with centralized issuance | The fleet is growing, short access lifetime and unified access policies for all hosts are needed | You need your own certificate authority and its maintenance; hosts must trust it; issuance and rotation procedures are required |
| Hybrid access mode | Transition period: new hosts are already on certificates, old ones are still on keys | Two trust perimeters at the same time; you need to know exactly who accesses what via static keys; the transition window must be bounded by a date |
A pure scheme almost never exists in practice: the host fleet is updated unevenly, and some machines still live with static keys.
Therefore, the transition is formalized as a separate stage with a closing date—otherwise the hybrid period turns into a permanent mode with double access accounting and extra points of failure.
Implementation order: from key audit to handover of procedures
The certificate implementation order is structured so that access to servers is not interrupted for a single on-call cycle. First we record the current state, then design the trust scheme, and only then issue certificates for real—first to a pilot group, then to the entire fleet.
- Fleet inventory. We collect a list of hosts, service accounts, and people who use SSH; note where static keys have settled and which ones have not been used for a long time. Without this map, it is impossible to understand which roles and principals are needed.
- Trust scheme design. We define issuance roles, the set of principals, certificate lifetimes, and signing templates; decide what to do with long-lived keys and how to arrange emergency access.
- Issuance setup. We deploy Vault as a certificate authority, connect it to the user directory, enable the issuance log and signature verification on the host side.
- Pilot group. We migrate 5–10 engineers and the on-call shift, check regular login, certificate expiration, and access revocation. If the on-call engineer cannot log in during an incident, the scheme is not ready.
- Phased fleet migration. We proceed in segments: first test and internal hosts, then production services, and critical nodes last. At each stage, the share of successful logins and the reasons for failures are visible.
- Handover of procedures. We hand over documentation: how to issue and revoke a certificate, what to do in case of compromise, the on-call procedure, and how to onboard new employees.
Access policies, roles, and documentation after implementation
After implementation, the customer has not only working certificate-based access but also a complete set of artifacts in their own repository. Without it, the solution turns into a black box that only the setup author can maintain. Below is what exactly we hand over and by what criteria we check that it can be used independently.
- Trust scheme. Where the certificate authority private key is stored, how hosts gain trust in it in the sshd configuration, which perimeters are separated by dedicated CAs rather than one common one.
- Signing roles. Role files for each group: certificate lifetime, allowed principals, set of extensions, prohibition of agent forwarding and arbitrary commands.
- Access policies. Mapping of roles and groups from the directory, separate rules for service accounts and on-call staff, the procedure for issuing out-of-plan access with the approver specified.
- Revocation procedure. How a single key is revoked and how access is revoked for an entire group, where the revocation list goes, how quickly it propagates to hosts, and how to verify that revocation occurred.
- On-call instructions. What to do if a key is lost, whom to escalate to, how to issue temporary access, and where to view the signing log for a specific employee.
- Audit and reports. Logging of every issuance: who, when, under which role, and with which principal; export to centralized log collection and retention period.
- Operational documentation. Environment diagrams, CA key rotation, onboarding new hosts, and restoring the CA from backup with trust verification on hosts.
Case study: migrating from long-lived keys to certificates
The client is a distributed fleet of several hundred servers across three perimeters.
Access was issued via SSH keys that lived for years: an employee's key remained valid even after termination, and there was no inventory of “who goes where.” Revocation turned into a separate task—approval, notification to teams, and manual editing of trusted key lists on every node.
How it was
An audit revealed about six hundred long-lived keys; some had not been used for more than a year but remained in trusted lists. The average revocation time after termination was several days, and during all that time the pass remained valid.
Login was performed with a shared key per role, so the logs could not distinguish who exactly accessed a node.
What was changed and what became
We deployed Vault as an SSH Certificate Authority: trusted CAs were written into node configurations, and keys began to be signed for a short period—a work shift instead of indefinite access.
Permissions were split by roles via principals and policies: a database administrator and an on-call engineer receive different sets of hosts.
Certificate lifetime is 8 hours, renewal is automatic while the session is active. Revocation takes minutes: the certificate goes into the revocation list, and nodes stop admitting the owner without manually going through the fleet.
The share of long-lived keys dropped to a few percent—service accounts with limited rights remained, and incidents involving active access of terminated employees stopped.
What to do if static keys are already deployed across the server fleet?
Migration does not require stopping access: on each node, the TrustedUserCAKeys directive with the certificate authority's public key is added to authorized_keys, and the server begins accepting both authentication methods simultaneously.
Static keys remain working, which means rollback at any step costs one line in sshd_config. This is exactly what makes the transition manageable: the old perimeter lives exactly as long as needed and is disabled deliberately, not during an incident.
The order of stages follows the rule “first expand trust, then narrow permissions.” First, inventory: who connects, to which nodes, from which addresses, and under which name—with static keys this is visible only indirectly, so the registry is assembled from logs and configurations.
Then trust in the CA is distributed across the fleet, then the certificates themselves are issued, and only after all traffic has gone through them are static keys removed from authorized_keys.
Compatibility with old servers is solved not by “update everything” but by separating into perimeters. Where there is a current OpenSSH branch or an updatable distribution, certificates are enabled as standard.
Nodes that cannot be updated—legacy builds, embedded systems, equipment with closed firmware—remain on local keys in a separate perimeter with strict restrictions on source addresses and validity period. This is not a compromise but an explicit boundary: it is documented and gradually reduced.
Contractors are a separate workstream. A certificate is issued not to a person in general, but to a role with a set of principals and a short lifetime, so access stops being indefinite.
Logs show a specific name and serial number instead of the line “a shared key connected”—during incident analysis, this is the difference between investigation and guesswork.
The transition concludes with the removal of static keys and the migration of access exclusively through certificates, while each perimeter retains a documented rollback method. We break down how to lay out such a transition in stages for your fleet.
Technical doubts: lifetimes, revocation, and compatibility
Questions at the start of implementation are almost always the same: how long a certificate lives, what to do upon termination, whether hundreds of hosts will have to be traversed manually, and what will remain in the logs.
Below are substantive answers: with parameters that we fix in the configuration and a description of how this behaves in real operations.
How short should a certificate lifetime be?
The working range is from several hours to one day for people and minutes for service tasks. Issuance occurs at the moment of connection, the private key never leaves the engineer's workstation, so a long lifetime provides no convenience, only risk.
A short lifetime works as a replacement for revocation: by the time access needs to be taken away, the certificate has most often already expired, and renewal happens imperceptibly for the person.
How do you revoke access if an employee has left but the certificate is still valid?
Two independent levels. The first is the certificate revocation list, which is distributed to hosts and picked up by the access service without restart and without breaking active sessions.
The second is blocking the account in the directory: in this case, renewal is simply not issued. The window in which the old certificate is still accepted is limited to minutes, not days.
How does the host verify that the presented certificate is authentic?
The host trusts only the public key of the signing authority—it is written into its configuration once. The signature is verified locally; there is no call to the CA at login time, so CA unavailability does not block operation.
Principals and additional restrictions inside the certificate define which accounts and hosts it applies to—the same key does not open everything at once.
What will be included in access logging?
The logs retain the certificate fingerprint and serial number, not just the username: a session can be linked to a specific issuance and it can be understood which key was used.
Records are collected into a common stream with a request identifier, so incident analysis does not turn into reconciling logs on every host.
Can it be implemented in stages without stopping operations?
Yes. First, the signing authority is brought up and one perimeter is migrated; regular keys continue to work in parallel.
Then host groups are migrated one by one; at each step, rollback is returning trust to the previous keys; it is reversible and does not require rebuilding the infrastructure.
Let's discuss the task: we'll design an access scheme for your perimeter
To make the assessment accurate rather than “based on feelings,” we need to see the current access landscape: how many machines are in the perimeter, how keys are issued today, and what should go into the log. Below is what to prepare for the conversation. We will gather this in one session and come back with an assessment and implementation plan.
- Fleet map: list of servers and stands, grouped by environments and criticality levels.
- Roles and principals: who belongs to which groups, what permissions are needed, who is granted temporary access.
- Current issuance: how keys appear now—manually, by script, via a panel, or via a domain account.
- Entry points: bastion, intermediate hosts, build runners, administrative subnets.
- Lifetime and revocation: maximum certificate validity period and procedure for immediate revocation upon termination or incident.
- Credential source: user directory, single sign-on service, or inventory—to link issuance to the staffing schedule.
- Perimeter constraints: isolated networks, no outbound access, audit requirements, and internal procedures.
- Target metrics: access issuance time, share of servers under certificates, volume of manual operations.
Based on this set, we will propose an access scheme for your perimeter: where the trusted CA is located, how roles, lifetimes, and revocation are arranged, what goes into the log, and how this is confirmed by verification.
Describe the task—we will come back with an assessment, a stage-by-stage plan, responsibility areas, and rollback points at each step.