SSH CA: centralized access management

SSH CA: Why Overgrown Static Keys Are Dangerous

The classic scheme looks like this: an engineer has a key pair, and the public part is copied into authorized_keys on every server that needs access. While there are five hosts and three people, this works.

When there are a hundred hosts, and contractors and on-call shifts connect to the front end, the file on each node turns into a list that no one can state accurately.

Revoking access in such a scheme is not a command but a search task. You need to remember all nodes where the key was once copied, including test benches and backup machines, and delete the line on each one.

While this traversal is underway, the key continues to work: the window between an employee leaving and actual deletion is measured in days.

Rotation of static SSH keys is almost never done: replacement means repeating manual distribution across all nodes, and a mistake causes access denial for the current shift.

Key auditing comes down to reading authorized_keys — you can see a set of lines, but not who owns it, when it was issued, or until when it is valid.

The overhead of the process grows with the number of nodes: each new machine adds a manual edit point, and each new person adds just as many.

Centralized access management via SSH CA breaks this link: a certificate is issued for a specific person or role and lives for a limited time, so revocation and auditing stop depending on the administrator's memory. We will break down how this is handled in practice.

What Unified Access Certificate Issuance Provides

The classic scheme is public keys distributed across authorization files on every server.

While the fleet is small, this works; as it grows, manual rotation appears, copies of keys from departed employees on dozens of machines, and the inability to revoke access quickly: to close one key, you need to go through all hosts. Shared keys in repositories and ghost accounts are a direct consequence of this model.

Unified access issuance moves the decision to a single certificate authority.

An engineer confirms identity (second factor, corporate sign-in), receives a short-lived access certificate, and works with it; the host verifies the authority's signature and the principal and permissions specified in the certificate, not the contents of the key file. Compatibility with OpenSSH is preserved — the source of trust changes, not the client.

A short-lived certificate is measured in hours, not months: a leak gives a window of tens of minutes instead of indefinite access.

Revocation also stops requiring a fleet-wide walk — it is enough not to renew the certificate or add it to the revocation list, and this applies across all hosts at once.

The access issuance log records who received a certificate and when, from which device, for which hosts, and for what period. Auditing turns into a query from the log, not correspondence with administrators.

Measurable consequences: the share of servers with static keys drops to zero, granting access to a new engineer takes minutes, full revocation is one operation instead of walking hosts, and the number of manual actions during onboarding and offboarding is reduced to role confirmation.

Access Formats: SSH CA vs Static Keys

Before choosing a format, it is worth fixing what exactly the host verifies at login: the holder of a private key or a certificate signed by a certificate authority with parameters.

Static keys in authorized_keys are the option without infrastructure: on a few hosts with an unchanging team composition, it is simpler and less effort than any implementation.

Then growth begins: authorization files have to be synchronized, revocation is done manually on each node, and an employee's departure changes nothing until the next walkthrough.

Certificates move the decision into a trusted zone: an intermediate signing node issues identification for a short term and limits it by accounts, source addresses, and a forced command.

Hosts only need to verify the signature and validity period — there are no key lists on them anymore.

Keep certificate limitations in mind in advance: a certificate issued before expiration cannot be revoked by standard means, so the term is made short and renewal is automatic.

The trusted zone becomes a critical element: its unavailability stops the issuance of new access, although already issued certificates continue to work. These trade-offs determine which format fits your fleet.

Implementation Step by Step: From Key Audit to Handover

Implementation begins not with server configuration but with inventory.

While it is unknown who goes where using keys, any trust scheme remains theory: we collect public keys from all machines, compare them with accounts, and mark "ownerless" ones — left over from contractors, interns, and departed employees.

The output is a registry where each key has an owner and purpose, and each server has a list of those who actually need access.

1. Key inventory. Collect and analyze authorized keys, find duplicates and keys with unlimited lifetime, and record current entry points and service accounts.
2. Trust scheme design. Determine where the certificate authority's private key lives, who manages it, which roles are included in the certificate, for what term it is issued, and how it is renewed.
3. Staging deployment. Stand up the certificate authority in an isolated environment, configure certificate verification on servers and the revocation procedure, so that lost access is terminated immediately rather than after manually editing all machines.
4. Staging validation. Run scenarios: issuance and renewal, denial after revocation, on-call login when the certificate authority is unavailable. Separately — emergency access that does not depend on the main scheme.
5. Migration. Move servers in groups, from peripheral to critical; old keys remain a fallback path until the new scheme has completed a full issuance and revocation cycle.
6. Policies and handover. Hand over documentation, issuance and revocation rules, the procedure for a lost key, and on-call shift training — after that, support operates without us.

Output Artifacts: Configurations, Diagrams, and Policies

The work ends not with a presentation but with a set of files and rules that the team immediately applies in the production environment. Below is what exactly remains in your repository and access system.

• Trust configurations on nodes: changes in sshd_config specifying the signing authority, principal policies, and a separate file with the authority's public keys.
• Roles and deployment scenarios: idempotent rollout of configurations across the entire machine fleet, including new and recreated nodes.
• Certificate issuance automation: lifetimes, permission sets by role, issuance for people and service accounts without manual operations.
• Trust scheme: a map of "signing authority — nodes — users", failure points, segment boundaries, and the authority key rotation procedure.
• Access policy: who receives it and on what basis, how temporary access is arranged, who approves it, and how it is recorded.
• Revocation procedure: certificate revocation lists, the time to deliver them to nodes, and on-call actions when a key is compromised.
• Audit and logs: where to look, who logged in and when, how events go to your log collection system, and how long they are retained.
• Documentation and handover: instructions for on-call staff, authority recovery procedure, change log, and review with the team.

Six months later, a new engineer issues access, revokes it, and brings the authority back up using these materials — without hunting for the person who created the configuration.

Case Study: Access Revocation in Minutes Instead of Several Days

In one project, access to 40+ servers was granted by copying public keys according to inventory. An engineer's departure turned into walking all hosts and cleaning authorized_keys: full revocation took 2–4 days, and all that time access remained active. A shared key for the team completed the picture — logs could not show who exactly connected.

Authentication was moved to SSH CA: the certificate is signed for a short term and contains access roles, so it is not transferred between people and is not reused.

The trusted authority's private key is stored in HashiCorp Vault and does not leave the vault, while issuance is performed by request with a log entry.

Revocation no longer depends on administrators' promptness: the certificate is valid for a limited time, and during an incident it is added to the revocation list, which the host checks on every connection.

The failure class "residual access after departure or key leak" is closed by process, not by policy. The role scheme and host rules are covered later on this page.

What to Do If the Fleet Already Runs on Static Keys?

Migration to centralized issuance does not require a "day X" when everyone is simultaneously stripped of static keys. The SSH daemon reads both trust sources at once: the file with the authority's public key and the familiar authorized keys list work in parallel.

While both are specified in the host configuration, the fleet is migrated in groups — by team, by environment, or by machine type.

It all starts with inventory: who goes to which hosts, under what names, and what restrictions are currently hardcoded in static records.

Then the authority's public key is added to trusted keys on hosts, and certificates are rolled out to the hosts themselves so clients stop complaining about a key change on first connection.

Next is a transition period with dual trust. New employees and services receive only short-lived certificates, old static keys remain working but are not reissued.

Restrictions — forced command, allowed addresses, prohibition of port forwarding — are moved from static records into certificate parameters, so permissions transfer one-to-one rather than expanding "just in case".

Emergency access is designed separately: one service key outside the common environment, stored according to procedure and used if the issuance service is unavailable. It covers the main risk of migration — complete loss of access to hosts — and also serves as the rollback plan.

When logs show that the last static key is no longer used, the authorized keys list is removed, and the authority remains the only issuance point.

Common Technical Objections and Engineers' Answers

Engineers rarely argue with the idea of SSH CA itself — details raise questions: where the root key lives, what happens if the signing node fails, and how to revoke already issued access.

The protocol is supported by OpenSSH without extensions, so doubts are usually not about the principle but about operations. Below are typical objections and how they are addressed.

What happens if the issuance node is unavailable?

Signing does not require constant online presence: a certificate is issued for the duration of a work session and remains valid regardless of the node's state.

The root is kept in cold storage, while day-to-day signing is performed with an intermediate certificate — if the medium fails, a new intermediate is issued, and trust on hosts does not need to be reset.

How do you revoke access if an issued certificate is still valid?

The primary mechanism is a short lifetime: the certificate expires in hours, not years. For immediate revocation, a revoked key list is published, and the principals under which the user logged in are removed. Hosts reread the list — access disappears without reissuing keys across the entire machine fleet.

Let's Discuss Your Access Scheme and Come Back with a Plan

To offer an assessment rather than generalities, we need to see your access scheme: how keys are currently issued, where they are stored, and who manages permissions on servers.

Describe the task — we will come back with a work plan and an analysis of the risks of moving to SSH certificates instead of long-lived keys.

During the discussion, we will cover:

• the current access issuance procedure and places where keys are copied manually;
• fleet composition: operating systems, cloud and on-premises servers, and hardware where updating the configuration is most difficult;
• roles and groups: who needs which servers, and by what attribute this is determined;
• requirements for login logging and certificate lifetimes;
• procedure for revoking access upon employee departure or role change;
• rollback mode if some servers do not support the new authentication method;
• deadline constraints and work that cannot be stopped.

Based on the results, you will receive an effort estimate, a phased work plan, and a target access scheme describing what changes on the server side and what changes in client configuration.

If a full migration is not justified right now, we will propose a phased option: first part of the fleet, then the rest, while preserving the current login method during the transition period.