SSH certificates have been around for several years and more organizations are adopting SSH certificates as a way to avoid some of the risks that come with standard SSH key pairs.
SSH certificates offer a fantastic method to solve some pain points growing teams and infrastructure. SSH certificates are digitally signed objects that have metadata like username/hostname, restrictions, end date, and more. This helps avoid many of the challenges and risks associated with traditional SSH keys because usage can be tracked and, like TLS certificates, they automatically expire.
SSH certificates can be cryptographically verified and, like traditional SSH keys, are exchanged between client and host during the SSH handshake. How exactly do SSH certificates work to secure your organizations machine identities?
SSH Machine Identity Management for Dummies
Validity period and revocation
A major advantage of SSH certificates is the validity period. They are valid for only a specific period and after that they will no longer be trusted. The validity period can be days, hours, even minutes.
It’s even better when using short-lived certificates. Administrators will no longer need to make sure that the revocation lists are populated with revoked certificates. If an employee loses access (e.g., if they leave the company), their existing certificate will expire, and they will not be able to get a new one. This passive revocation is an advantage in the case of a compromised private key. If there is a lost or stolen laptop, a short-lived SSH certificate is worthless for accessing internal infrastructure by an unauthorized third party.
User onboarding and offboarding
Many organizations have described processes of onboarding and offboarding users that includes SSH access. It’s not surprising that security regulations around these processes are not always strictly adhered to. Throughout the years, as administrators leave and new administrators come join, old keys get left behind. Not knowing what old keys are left behind is a major problem, as it is unlikely new administrators will be able to regenerate and replace all existing keys that are in use.
When using SSH certificates, the onboarding process is simplified to issue a new certificate for every new administrator. As servers are trusting a certificate authority, rather than individual public keys, there is no need to configure each server.
When offboarding users that are using short-lived certificates, you can simply allow them expire without renewing them, and certificates can be revoked if they are valid for long periods of time.
Trusting remote servers
When a client is connecting to a server for the first time, the user is prompted to verify the public key of the server. Once accepted, the client will not prompt the user again unless there is a new public key. This process is called Trust on First Use (TOFU).
When using traditional SSH keys, you need to put the public keys of all your servers on all client devices. This is not a big deal if organizations are using bastion (aka jump) servers. Otherwise, this can be a challenge.
Trusting a certificate authority by adding its public key is a very simple process. This will allow organizations to add new servers or replace them without administrators to see the "host key has changed" error messages.
Host certificates allow multiple hosts to share a principal without needing to share the same private key, which is incredibly useful when using load balanced SSH connections.
Get a FREE & Confidential SSH Risk Assessment from Venafi!
Related posts
- Best Practices for Multi-Cloud SSH Key Management
- Poorly Managed SSH Keys Are A Favorite Target for Malware
- SSH Vulnerability Allows Authentication Without a Password