SSH Certificate vs Key Authentication on Ubuntu
This article explains the differences between SSH certificate-based authentication and standard SSH public key authentication on Ubuntu Linux. It covers how each method works, compares their security and scalability, and details why certificate-based authentication is the preferred choice for managing access in enterprise Ubuntu environments.
Understanding Standard SSH Key Authentication
Standard SSH authentication relies on asymmetric cryptography using a public and private key pair.
- How it works: A user generates a key pair on their
local machine. They copy the public key to the target Ubuntu server and
append it to the
~/.ssh/authorized_keysfile. The private key remains securely on the user’s local machine. - The verification process: When connecting, the server challenges the client to prove they possess the matching private key.
- The limitation: As organizations grow, managing
standard keys becomes difficult. Every time a user joins, leaves, or
changes roles, administrators must manually update the
authorized_keysfile on every single server the user needs to access. There is also no built-in way to enforce key expiration.
Understanding SSH Certificate-Based Authentication
SSH certificate-based authentication introduces a centralized trust model using a Certificate Authority (CA). Instead of servers trusting individual user keys, they trust a single, central CA.
- The Certificate Authority (CA): Administrators generate a master SSH key pair to act as the CA. The public portion of this CA key is copied to all Ubuntu servers.
- Signing process: A user generates a standard SSH key pair. Instead of copying their public key to the servers, they send it to the CA. The CA verifies the user’s identity and signs the public key, generating an SSH certificate (a public key packaged with metadata).
- The metadata: This certificate contains cryptographic proof of the CA’s signature, the username, and constraints such as an expiration time (Time-To-Live) and permitted source IP addresses.
- The verification process: When the user connects to an Ubuntu server, they present their certificate. The server verifies the CA’s signature on the certificate. If the signature is valid and the certificate has not expired, access is granted.
Key Differences
| Feature | Standard SSH Keys | SSH Certificates |
|---|---|---|
| Trust Model | Direct trust (Server trusts individual keys) | Centralized trust (Server trusts the CA) |
| Server Configuration | Requires updating
authorized_keys for every user |
Configured once with the CA public key |
| Expiration | Permanent unless manually deleted | Built-in expiration dates (TTL) |
| Scalability | Poor; difficult to manage across many servers | High; seamless addition and removal of users |
| Revocation | Manual deletion from target servers | Handled automatically via expiration or Key Revocation Lists (KRLs) |
How SSH Certificates Work on Ubuntu Linux
To implement certificate-based authentication on Ubuntu, the OpenSSH
daemon (sshd) must be configured to trust the CA.
1. Configure the Ubuntu Server to Trust the CA
The CA’s public key (e.g., ssh-ca.pub) is copied to the
server, usually to /etc/ssh/ssh-ca.pub.
To instruct Ubuntu to trust this CA for user logins, the
/etc/ssh/sshd_config file is updated with the following
directive:
TrustedUserCAKeys /etc/ssh/ssh-ca.pub
2. User Authentication Flow
Once the SSH daemon is restarted
(sudo systemctl restart ssh), the login workflow
changes:
- No localized keys: The
~/.ssh/authorized_keysfile on the target server can remain empty. - Instant provisioning: If a new developer joins the team, the CA signs their key with a 12-hour expiration window. The developer can immediately log into any Ubuntu server trusting that CA without any server-side configuration changes.
- Automatic revocation: Once the 12-hour window passes, the certificate becomes useless, mitigating the risk of orphaned keys.