What are SSH Certificates?

The concept of SSH certificates is that instead of using public key authentication, you are instead using certificate authentication. SSH certificates are already supported on all Linux/Unix systems.

SSH certificates contain a public key, identity information, and validity constraints. They are signed by a certificate authority with a standard private key. (We'll show you how to configure SSH Protect to function as that certificate authority. SSH certificates can be used for both client and host authentication.

In a traditional SSH key environment you have the concept of client keys and host keys. Together they establish trust between two machines. The client has the host's public key, and the host has the client's public key; they know they can trust each other and that communication between the two machines is authorized.

SSH certificates work the same way. The client has an SSH certificate signed by a CA that the host trusts. The host has an SSH certificate signed by a CA that the client trusts. (SSH Protect acts as this trusted CA for both the host and client certificates). The signed certificate data, managed by the CA, tells the host if a specific client is authorized to connect to that particular host. So, just because the client and host certificates are issued by the CA does not automatically give the client access to all hosts. However, since these are managed centrally, it makes managing SSH authentication much simpler and faster for SSH administrators.

In practice, from the host perspective, it is the Principals field on the SSH certificate, that during the SSH handshake, is populated by OpenSSH with the clients allowed to log in. Likewise, the SSH client looks in the Principals field to find the target hostname, so the cliSent knows it can trust the host it has connected to.

Principals

A key concept of an SSH certificate is the Principal. A principal defines what entities a certificate is valid for.

For user certificates, the principal is usually the username of the person who is using the certificate.

Organizations that are having many SSH users may prefer to not put usernames as Principal. Instead, they might put group names (e.g.: EMEA-root, or EMEA-database). When group names are used, the target systems have to be configured to accept the groups as principal names. However, it is important to note that even if the username is not specified as principal, the certificate identifier (Key ID) can be used for accountability of the person who made the connection, an important component of an audit trail to know which actual user accessed a given system.

For host certificates, the principal is usually the fully qualified domain name (FQDN) of the server.

Certificate Identifier (Key ID)

In practice, a certificate identifier (or Key ID) is usually used for auditing and tracking purposes. When used, it can contain information that uniquely identifies the client (human or application) which uses the certificates. In case of successful SSH authentication, the certificate identifier is printed to the authentication logs of the host server.

Extensions

Extensions allow administrators to enable privileged SSH features for client certificates like agent-forwarding or port-forwarding. Extensions are not applicable to host certificates.