We generally use either login credentials or SSH public-private key pair to login to Linux servers via SSH. However, both of them have their flaws. This made me wonder if there was a better way to authenticate users and hosts(servers):?
I came across SSH certificates which are quite similar to PKI using SSL (not exactly tho)
Before understanding more about SSH certificates, we shall see what downsides traditional username-password-based and ssh keys-based auth have.
Drawbacks of traditional SSH auth methods
Username Password drawbacks:
- Password expires quite frequently on multiple servers.
- Username Password may get stolen or leaked
- Passwords get very difficult to manage in very large environments .. eventually leading to opting for an easy password or password reuse
SSH public-private key-pair drawbacks
- The key generated is not linked to a single or selected group of users/entities
- User B can use User A's SSH keys to log in
- The public key must be present in each server's authorized key file
- Keys don't expire!
Now that we understood the drawbacks, let's understand what even are SSH certificates.
What are SSH certificates
[Without using a lot of technical jargon]
When we use SSH certificates, we have 3 entities that we need to consider.
- User : The user who will login
- Host : Server we are trying to login to
- CA : A trusted authority that will sign certificates. Thus creating trusted certificates that avoid certificates generated by some random person/entity.
The certificate generated as a result of signing the user or host public key with the private key of CA will be used instead of the public key. Just like keys are exchanged in key-based authentication, certificates are exchanged in this method.
How SSH certificates are generated and used
[ Contains theoretical explanation. The actual detailed demonstration can be found here]
On the CA / Trusted Server, we have the ca private key which will be used to digitally sign the user and host keys, and a certificate will be generated as a result of this process.
For instance: we have user keys as user1 and user1.pub, CA keys as ca and ca.pub
The ca private key file will be used to sign the user1.pub with details like expiry period, and usernames (principal names) that can use this certificate.
On signing, we get a user1-cert.pub certificate file.
When we log in to a server using our private key in the argument eg. ssh -i keyname user@host , the ssh client will also check for a certificate file ending in -cert.pub. This will be sent to the server.
Conditions are checked like:
- If the username (principal name) in the certificate is the same as the user trying to login
- Is the certificate signed by the trusted CA
- Other conditions like whether the certificate is expired or not etc.
If all checks are successful, the user is logged in.
Can the SSH certificates be revoked?
Yes, the certificates can be revoked by keeping the public key (.pub) or the certificate (-cert.pub) value in a file. This file can be referenced in the RevokedKeys config in the sshd.config file.
Are SSH certificates and X.509 certificates the same?
No, they aren't.
Detailed blog by teleport on the difference between the two.
That was it for an introduction and basic understanding of SSH certificates.
Step by step guide to implement SSH certificates can be found here.