Why use an SSH certificate authority on Linux
For Linux infrastructure, an SSH certificate authority provides scalable, auditable SSH authentication, removing the need to distribute raw public keys to every server. Instead of managing a growing set of authorized keys on each host, you sign short lived user and host certificates, and configure trust centrally.
SSH certificates reduce operational errors, simplify onboarding, and improve security posture. They make automated rotation, expiration, and least privilege enforcement practical for fleets of servers, containers, and jump hosts.
Planning and prerequisites
Before you build a CA, decide whether you will use a single CA for both user and host certificates, or separate CAs to limit blast radius. Choose secure key formats, prefer ed25519 or ecdsa over legacy RSA, and plan a rotation schedule.
Install OpenSSH server and client packages, and ensure you have root or sudo access on the CA machine and on example target servers. Prepare a secure directory for private CA keys, with strict permissions.
- Required packages: openssh-client, openssh-server, and a configuration management tool for automation
- Decisions to make: separate user and host CAs, certificate lifetime policy, and automation approach
Generate the CA keys
Create the CA key pair on a dedicated, hardened machine, ideally offline or in an HSM. Use a secure passphrase and protect the private key file with file permissions and access control. Example commands are shown for reference.
Store the public CA keys where clients and servers can read them, for example in /etc/ssh on managed hosts, or in a central configuration repository used by your provisioning system.
ssh-keygen -t ed25519 -f /etc/ssh/ssh_ca_user_key
ssh-keygen -t ed25519 -f /etc/ssh/ssh_ca_host_key
chmod 600 /etc/ssh/ssh_ca_user_key
chmod 600 /etc/ssh/ssh_ca_host_key
Sign host certificates
To sign a host certificate, collect the host public key and issue a certificate that includes the host principals. Host certificates prove server identity to clients that trust the host CA. Typical lifetimes are measured in days rather than years.
After signing, distribute the host certificate to the server and configure the SSH daemon to use it. Clients will trust the server when the client known hosts file or global known hosts file contains the CA public key with the cert authority marker.
ssh-keygen -s /etc/ssh/ssh_ca_host_key -I host.example.com -n host.example.com -V +52w /etc/ssh/ssh_host_ed25519_key.pub
# copy the resulting certificate to the server as /etc/ssh/ssh_host_ed25519_key-cert.pub
Sign user certificates and enforce short lived certs
User certificates embed principals and optional extensions such as source address limits. Issue user certs with short lifetimes to limit exposure if a key is stolen. Use the principals field to map to system accounts, and require AuthorizedPrincipalsFile or AuthorizedPrincipalsCommand on servers for fine grained control.
Short lived certs are enforced by expiration time embedded in the certificate. Pair that with enforcement logic on the server using AuthorizedPrincipalsCommand or a central SSO hook to restrict or revoke access dynamically.
ssh-keygen -s /etc/ssh/ssh_ca_user_key -I alice -n alice -V +8h alice_key.pub
# distribute alice certificate alice_key-cert.pub to client user home or agent
Automate issuance with scripts and Ansible
Manual signing is slow and error prone. Automate certificate issuance with small scripts, or integrate signing tasks into Ansible playbooks for predictable, auditable issuance. Create a signing service that validates requests before signing.
Automation should implement checks, for example verifying identity via an SSO token, ensuring requested principal lists match directory records, and limiting requested lifetimes. Log all signing actions for audit and troubleshooting.
- Script tasks: fetch public key, validate requester, sign, return certificate
- Ansible: use a central signing playbook and templates to push public CA files and certificates to hosts
Configure OpenSSH trust and rotation
On servers, configure /etc/ssh/sshd_config to trust user certificates by pointing TrustedUserCAKeys to the CA public key. For host trust, deploy the host CA public key to clients known hosts as an authority entry so clients accept certificates signed by your host CA.
Plan key rotation: issue new CA keys on a schedule, sign new certificates with the new CA, and deploy new CA public keys before rotating the private key. Maintain overlap so existing certificates remain valid during migration.
# sshd_config snippet
TrustedUserCAKeys /etc/ssh/ca_user.pub
AuthorizedPrincipalsFile /etc/ssh/authorized_principals/%u
Revocation and best practices
OpenSSH does not provide a built in certificate revocation protocol. Best practice is to rely on short lived certificates, use separate CA keys for users and hosts, and implement runtime deny lists via AuthorizedKeysCommand or AuthorizedPrincipalsCommand to block specific principals or keys.
Other hardening measures include storing CA private keys offline, using HSMs or sealed vaults where possible, logging every signing event, and enforcing multi person approval for signing high risk requests.
- Rotate CA keys regularly and maintain overlap for smooth migration
- Use short lifetimes, centralized logging, and automated request validation
- Limit CA access to a small, audited team and protect keys with HSM or vault
FAQ
Common operational questions appear during adoption. Below are concise answers to help you avoid pitfalls when deploying an SSH certificate authority on Linux.
Each answer focuses on practical operations and integrates with configuration management and existing identity systems.
- Can I use a single CA for both hosts and users? Yes, but separation is recommended to reduce risk. Using separate CA keys limits impact if one private key is compromised.
- How do I revoke a certificate immediately? Because OpenSSH lacks a built in revocation protocol, use short lived certificates and implement a deny list via AuthorizedKeysCommand or AuthorizedPrincipalsCommand to refuse specific principals or keys at authentication time.
- How should I rotate CA keys? Generate a new CA key, publish the new public key to clients and servers, start signing new certificates with the new CA, and after a safe overlap period, retire the old key. Automate the steps through your configuration management tool.
- Are ed25519 signed certificates supported? Yes, use modern key types such as ed25519 or ecdsa for better security and smaller key sizes. Avoid legacy weak algorithms unless compatibility requires them.
Conclusion
Implementing an SSH certificate authority on Linux transforms SSH key management from a brittle, manual process into a scalable, auditable system. By signing host and user certificates, enforcing short lived credentials, and automating issuance, you reduce operational overhead and improve security. The core steps are straightforward, generate strong CA keys on a hardened machine, publish the public CA keys to servers and clients, and create automated workflows to issue certificates following your identity and access policies.
Operational success depends on planning certificate lifetime policies, building automation that validates requests, and integrating with your configuration management system for CA public key distribution and rotation. For revocation use short lived certificates and runtime deny lists. Treat the CA private key as a critically sensitive asset, protect it with strict access controls, and log every signing action for auditability. With these measures in place you can scale SSH access for large Linux fleets while maintaining strong security controls, rapid onboarding, and predictable operations.