Centralized SSH Authentication with Public‑Key Certificates: Architecture, Design, and Operational Guidance

Problem & Takeaway

Managing SSH access for a fleet of servers traditionally means distributing and rotating each user’s key pair per host. That approach scales poorly, introduces audit gaps, and makes revocation cumbersome. A single Certificate Authority (CA) that issues signed SSH public‑key certificates solves these pain points: it centralizes key management, enables fine‑grained access control, and reduces operational overhead.

Requirements

• All hosts and clients run OpenSSH 7.2 or newer (preferably 8.9+ for built‑in revocation).
• CA private key stored in a protected location (HSM, cloud KMS, or encrypted file with strict permissions).
• CA public key distributed to every host via the TrustedUserCAKeys directive.
• Client key pairs (private key + public key) generated per user, never stored on the host.
• Optional: critical options such as force-command or source-address for per‑user restrictions.

Minimal Design

The architecture consists of three logical components:

1. Certificate Authority: Generates and signs user certificates. The CA’s private key is never exposed to servers.
2. Server Trust Store: Each host loads the CA public key using TrustedUserCAKeys /etc/ssh/trusted_user_ca_keys in /etc/ssh/sshd_config.
3. Client Credential Bundle: Users keep a private key (id_rsa) and its signed certificate (id_rsa-cert.pub). The client references both when connecting.

Server Configuration Example

# /etc/ssh/sshd_config
# Enable the CA public key
TrustedUserCAKeys /etc/ssh/trusted_user_ca_keys
# Optional: enforce certificate-only authentication
# PasswordAuthentication no
# ChallengeResponseAuthentication no

Place the CA’s public key in /etc/ssh/trusted_user_ca_keys with chmod 644 and ensure it is read‑only.

Client Configuration Example

# Generate user key pair
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""
# Sign the public key with the CA (run on a trusted CA host)
ssh-keygen -s /path/to/ca_key -I [contact removed] -V +52w -z 1 ~/.ssh/id_ed25519.pub
# Copy the resulting certificate to the client machine
scp ca_host:~/.ssh/id_ed25519-cert.pub ~/.ssh/
# Connect using the certificate
ssh -i ~/.ssh/id_ed25519 -o CertificateFile=~/.ssh/id_ed25519-cert.pub user@target-host

In most setups, the CertificateFile option is optional if the certificate resides next to the private key with the -cert.pub suffix.

Trust & Data Boundaries

• Trust Anchor: The CA private key is the sole trust anchor. Protect it with an HSM or KMS and enforce strict access controls.
• Certificate Scope: Each certificate contains a valid-from and valid-to timestamp, a unique serial number, and a critical options list. These enforce per‑user policies without touching host configuration.
• Revocation Path: OpenSSH 8.9+ supports a server‑side revocation list file. Older versions require manual revocation via ssh-keygen -R or external lists.

Operational Checks

1. Verify CA Key Distribution: On each host, run ssh-keygen -lf /etc/ssh/trusted_user_ca_keys to confirm the CA public key is present and correctly formatted.
2. Test Authentication Flow: Generate a test key, sign it, and attempt to SSH into a host. Expect a successful login without password prompts.
3. Validate Revocation:
   • On a host with OpenSSH 8.9+, create a file /etc/ssh/authorized_keys_revoked containing the revoked certificate’s fingerprint.
   • Restart sshd and confirm that the revoked certificate is rejected.
4. Critical Option Enforcement: Sign a certificate with source-address=192.168.1.0/24 and verify that connections from outside that subnet fail.

Failure Modes

• CA Key Compromise: All certificates become trustable. Mitigation: rotate the CA key, revoke all certificates, and issue new ones. Keep audit logs of key usage.
• Outdated SSH Versions: Hosts or clients lacking certificate support will reject authentication. Ensure all nodes run a compatible OpenSSH release before rollout.
• Revoke List Staleness: In pre‑8.9 environments, the ssh-keygen -R command must be run on each host after revocation. Automation scripts are recommended.
• Misconfigured Critical Options: Incorrect force-command or source-address values can lock out legitimate users. Use test environments to validate critical options before deployment.

When to Re‑Design

• Scaling Beyond Thousands of Hosts: If the number of hosts grows to a point where managing a single TrustedUserCAKeys file becomes unwieldy, consider a hierarchical CA structure or per‑region CA keys.
• Introducing Multi‑Factor Authentication: If the security policy requires MFA, integrate SSH certificates with an external authentication system (e.g., Duo, Google Authenticator) that can issue temporary certificates.
• Regulatory Changes: New compliance requirements that mandate hardware‑based key storage may necessitate moving the CA private key entirely into a dedicated HSM or a regulated cloud KMS.
• Operational Tooling Constraints: If existing configuration management tools (Ansible, Chef) cannot handle the certificate workflow efficiently, a custom automation layer or a dedicated certificate management platform may be warranted.

Practical Verification Checklist

• Confirm TrustedUserCAKeys is enabled and points to the correct file.
• Verify CA public key fingerprint matches known value.
• Attempt a certificate‑based login and check ssh -vvv logs for "Authenticated via certificate".
• Revoke a test certificate and ensure the host denies access.
• Validate that critical options are enforced (e.g., source‑address restriction).

Conclusion

Using a central SSH CA to issue public‑key certificates streamlines key management, enforces fine‑grained access control, and aligns with zero‑trust principles. The design is minimal yet robust, with clear trust boundaries and operational checks that keep the system secure and auditable. By following the steps above, you can deploy a scalable, certificate‑based SSH infrastructure that reduces administrative overhead and strengthens security posture.