Hardening SSH - Key safety with a CA

30 Jul 2023

When configuring SSH for a server some questions of securing access should naturally arise. One possible use case is discussed in this post.

These questions could be:

Is login possible with a password?
Are all known-host files hashed properly?
Is the connection established without checking the fingerprint?
Is the fingerprint attached to a DNS entry (SSHFP)?
Is login only possible with a ssh-key?
Is this key rolled over regularly?
Is this key password protected?
Is key length and cipher appropriate / safe?
Was the key accidently uploaded in a git repository?
Does a key revocation list exist?
Is the user authorized with a proper user certificate?
Has the certificate a proper expire time?
Does a CA exist which certificates trust of the keys?

In this article, an SSH key CA is created and the scenario where a compromised key needs to be revoked is considered. To begin with, the following commands would create four SSH certificates and set them up to be used with the correct intent. This should be done on the CA host:

# ca, cwd: /etc/ssh
for i in client server ca bad; do
  ssh-keygen -qN pass -t ed25519 -f $i
done
ssh-keygen -s ca -I "Server ID" -n "$(hostname --fqdn)" -V "-5m:+4w" -h server.pub
ssh-keygen -s ca -I "User ID" -n "username" -V "-5m:+4w" client.pub
ssh-keygen -s ca -k -f krl bad.pub

The s-flag is used to use the created CA key and to signal that a key needs to be signed with it. The I-flag then sets the corresponding user key to be signed. Principal information is added with the n-flag. Generally this is the FQDN or the username for user keys. When verifying access the principal name must match a pattern section in the sshd_config. Lastly V is used for setting a time range where the key should be valid and h is used to generate a host key instead of a user.

The last command makes sure that a key revocation list is created and that the compromised key is added to it. Then, after all the important files have been uploaded to the server, the following changes need to be made to the sshd config file on the server:

# server, cwd: /etc/ssh
printf "%s\n%s\n%s" "HostCertificate /etc/ssh/server.pub" "TrustedUserCAKeys /etc/ssh/ca.pub" "RevokedKeys /etc/ssh/krl" >> /etc/ssh/sshd_config;

These lines make sure that

the server knows which certificate can be used to present to clients,
which user certificates are valid and
which of these are not anymore.

Then, on the user host, the server can be declared trusted by adding the public ca certificate to the known hosts file:

# client, cwd: ~
printf "%s" "@cert-authority <server.fqdn> $(cat ca.pub)" >> ~ssh/known_hosts
ssh-add ~/ssh/client-cert.pub

As a client certificate is used for authentication it is generally possible to further restrict the actions that are allowed on the server with this certificate. For example, a command may not be executed until a connection has been established. Another option is to define a source IP address that must be matched before a connection to the server is possible.

Further reading: ssh-keygen(1), ssh-add(1) and sshd(8).