Scaling SSH with OpenSSH Certificates: A Practical Architecture Note

Problem

In a distributed environment with hundreds or thousands of servers, distributing and rotating SSH keys for each user is cumbersome. Traditional key‑based authentication requires manual key distribution, makes revocation difficult, and offers no fine‑grained control over which hosts a user may access. The goal is to replace per‑user keys with a single, centrally signed certificate that can be revoked, scoped, and automatically distributed across the fleet.

Requirements

• OpenSSH 7.2+ on all servers (certificate support added in 7.2).
• Central CA private key stored on a hardened appliance or HSM.
• CA public key published to every target host via TrustedUserCAKeys.
• Clients generate normal key pairs (e.g., ed25519) and sign them with the CA.
• Revocation list maintained and distributed to all hosts.
• All hosts enforce PubkeyAuthentication yes and disable password fallback.

Minimal Design

The architecture consists of three logical components:

1. CA Server: Holds the CA private key and signs user keys. It also publishes the CA public key and the revocation list.
2. Client Machines: Generate a key pair, obtain a signed certificate from the CA, and use it to authenticate to any host that trusts the CA.
3. Target Hosts: Run sshd configured to recognize the CA public key and consult the revocation list.

With this setup, a user’s SSH session is authenticated by a signed certificate that includes a validity period, a list of allowed hostnames, and a unique identity string. The certificate is short‑lived (e.g., 52 weeks) to limit exposure if the private key is compromised.

Trust & Data Boundaries

• The CA private key never leaves the secure appliance. Client machines only ever see the public key and signed certificates.
• The CA public key is stored in a read‑only location (e.g., /etc/ssh/trusted_user_ca_keys/ca.pub) on each host.
• Revocation lists are distributed as plain text files (e.g., /etc/ssh/revoked_keys) and referenced by RevokedKeys in sshd_config.
• All communication between clients and the CA for signing is authenticated (e.g., via HTTPS or SSH itself) and encrypted.

Operational Checks

After deployment, perform the following verifications to ensure the system is functioning correctly.

1. Verify CA public key distribution

   # On a target host
   grep -q 'ca.pub' /etc/ssh/sshd_config
   # Check file exists and is readable
   ls -l /etc/ssh/trusted_user_ca_keys/ca.pub
   

2. Test a signed certificate login

   # Generate client key
   ssh-keygen -t ed25519 -f /tmp/user1_id
   # Sign the key via CA
   ssh-keygen -s /path/to/ca_key -I user1 -V +52w -z 1 /tmp/user1_id.pub
   # Attempt login
   ssh -i /tmp/user1_id user1@target-host
   # Expect log entry: "Accepted publickey (certificate)"
   

3. Test revocation

   # Add the certificate fingerprint to revocation list
   printf '%s
   ' '1:user1:target-host:2026-10-07' >> /etc/ssh/revoked_keys
   # Reload sshd
   systemctl reload sshd
   # Attempt login again
   ssh -i /tmp/user1_id user1@target-host
   # Expect denial and log message about revocation
   

4. Validate certificate expiry

   # Sign with a short validity period
   ssh-keygen -s /path/to/ca_key -I user2 -V +1d -z 2 /tmp/user2_id.pub
   # Wait until the day after
   ssh -i /tmp/user2_id user2@target-host
   # Expect failure: "certificate expired"
   

Failure Modes & Mitigations

• CA key compromise: All certificates become untrustworthy. Mitigation: store the private key in an HSM, rotate the CA key regularly, and maintain an emergency revocation list that can be distributed immediately.
• Stale revocation list: A revoked certificate may still succeed until the host reloads sshd_config. Mitigation: automate revocation list distribution via configuration management tools and reload sshd on update.
• Misconfigured sshd_config: If TrustedUserCAKeys points to the wrong file or is omitted, certificate authentication silently falls back to passwords. Mitigation: enforce PasswordAuthentication no and audit sshd_config with sshd -T.
• Incorrect host list in certificate: A certificate may list unintended hosts, granting over‑permissive access. Mitigation: generate certificates with the -h flag to restrict to specific hostnames and validate with ssh -vvv.

When to Re‑Design

Consider changing the architecture if:

• The fleet grows beyond the capacity of the current revocation distribution mechanism (e.g., >10,000 hosts).
• You need per‑user or per‑host policy enforcement beyond what certificates provide (e.g., role‑based access control). In that case, integrate with an external policy engine or use authorized_keys with command= restrictions.
• The CA private key is compromised and you cannot quickly rotate it. A more robust key management system (e.g., AWS KMS, Azure Key Vault) may be required.
• Operational complexity (e.g., managing multiple CA keys for different regions) outweighs the simplicity of a single CA.

Conclusion

Using OpenSSH certificates signed by a central CA provides a scalable, revocable, and fine‑grained authentication mechanism for large fleets. The minimal design relies on secure key handling, consistent sshd_config across hosts, and diligent revocation management. By following the operational checks and being aware of failure modes, you can maintain a robust SSH infrastructure that adapts to growth and threat evolution.