What is an SSH Certificate-based authentication?
To understand SSH certificates, we must first understand SSH key-based authentication. Asymmetric cryptography authentication will include two key pairs, a private and a public key. The private key can be generated via the command ssh-keygen within your terminal and is never to be shared, it is recommended to secure your private key with a password in case of any copies being made or loss, the private key than would not be accessible to an unauthorized entity. While a public key is derived from the private key and can be shared with others.
With such key-based authentication practice, the server and user must include their private key. The user can use the ssh-keygen command to generate their key, while the server usually generates one after the SSH server has been installed. During the access process, a user connects to the server via SSH. The server is required to authenticate the user. At this stage, the user provides the public key to the server while the server looks at the list of public keys that are trusted and accepted. If the public key is not found, the server rejects the connection.
On the other hand, the user also must confirm that the server is, in fact, the server they want to connect to. The user checks the server’s public key, checking the known_host file – a client file containing all connections known to the host that is connected remotely, authenticating the server and containing public keys of known hosts. Such a mechanism is based on security, as every user is required to have a list of pubic keys of the server they want to gain access to and vice versa for the server. Moreover, the public key lists of both server and the users require regulatory updates regarding any changes on either side.
What is an SSH Certificate-based authentication?
An SSH certificate is a public key that has been assigned by a trusted element or entity such as a certificate authority (CA), essentially holding the public and private key pair. Creating a certificate authority is recommended to be separate for either a host or user.
Here is an example of CA creation:
$ ssh-keygen -t ed25519 -f ~/.ssh/user_ca_key \ -C ‘User Certificate Authority for *.example.com’
During the creation process, it is necessary to assign fields by the CA. These fields would consist of an ID, public key, the validity of the CA, Key ID, valid Principles, Signature, etc. It is important to remember that the CA can issue a certificate as the certificate itself is just a public key with a digital signature. The best practice is to create a date range for a certificate so it can automatically expire; in other terms, have use validity. Lastly, within your configuration of the certificate, you can encode additional instructions regarding handling a certificate, such as port forwarding.
With the use of a certificate, the user and the server are not necessarily required to know each other’s public keys as they exchange their certificates and therefore can validate if the same CA singes them. It is important to note that the CA must be used to grant and sign from a well-trusted Certificate Authority. This goes in hand with any addition of a new server or user.
In the case of issuing a certificate, the following would take place:
1. A client or user would send its public key to the Certificate Authority.
2. A server would send its public key to the Certificate Authority
3. The Certificate Authority would act by granting and signing the certificates
4. Certificate Authority would issue the user certificate to the client and server.
To then use the certificate in practice, for example, in logging in, once both entities have their certificate:
1. The user or client sends the certificate to the server.
2. The server would validate the certificate whether the trusted certificate authority issues it.
3. After positive validation, the server sends its certificate to the user/client.
4. The client then validates the server certificate, whether it’s issued by the same trusted CA.
5. After positive validation, a connection is established.
Because of the almost seamless process and validations amongst entities and CA, the certificate-based authentication offers minimal involvement from the user/client side – users do not need to provide a password that can be cracked. Certificates can’t be forgotten as with passwords. Certificates contain an automatic expiration date, providing more security in contrast to long-lasting certificates. Lastly, certificates also contain additional information about the user, which can help in user management or monitoring scenarios.
To learn more, get in touch with our team and begin your secure access journey!
Author: Damian Borkowski– Technical Marketing Specialist
