SSH certificates: the better SSH experience

When I ssh into a server for the first time, I’m confronted with a dialog which asks me to verify I’m actually talking to the machine I expect to be talking to.

$ ssh -l jane 192.0.2.65
The authenticity of host '192.0.2.65 (192.0.2.65)' can't be established.
ED25519 key fingerprint is SHA256:4WTRnq2OR1m03TpnHCfkFdlh1gN/PBXE4vDi0WnjFEc.
No matching host key fingerprint found in DNS.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? 

It is likely that the majority of users cross their fingers and type ‘yes’, which is not really a clever response. This Trust on First Use (TOFU) is what permits SSH to ensure that my SSH client verifies which server it’s talking to. I ought to have asked the administrator of the server to tell me its fingerprint, and if I am the administrator I ought to know how to do this:

% ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
256 SHA256:4WTRnq2OR1m03TpnHCfkFdlh1gN/PBXE4vDi0WnjFEc root@d13 (ED25519)

If the two fingerprints compare equal, I can trust that I am connecting to the correct server and can continue with ‘yes’ or I paste a known host fingerprint into the prompt: trust on first use is accomplished.

SSH key pairs

If I create an SSH key pair, install my public key in the correct location (typically $HOME/.ssh/authorized_keys on the target node), and present the private key upon connection, then I don’t need to type the target user’s password; instead I enter the key’s passphrase to unlock the private key.

$ ssh-keygen -t ecdsa -C "JP's demo key" -f demokey
Generating public/private ecdsa key pair.
Enter passphrase for "demokey" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in demokey
Your public key has been saved in demokey.pub
$ ssh-copy-id -i demokey.pub [email protected]
...
$ ssh -i demokey [email protected]
Enter passphrase for key 'demokey':
jane@node:~$

I can avoid having to do that at every use of the key, by launching an SSH agent which I feed with my private key and it will then no longer requests a passphrase on use.

Disadvantages of the traditional approach

This is well known and has worked for very many years, but the required procedures for public key authentication to work come with some disadvantages:

• a copy of my SSH public key has to be available for each user I want to login as on a node
• TOFU typically causes the host fingerprint to be stored on my client (in the known_hosts file) - when a host key rolls, I get a big warning

When the server’s SSH host key changes, my client will loudly complain. In larger environments, this is something our users need to be made aware of, including how to correctly remedy the situation.

For those with dozens or even hundreds of servers and full control there-over, we can make all of the disadvantages above go away with an SSH CA (certification authority) and SSH certificates. That sounds complicated, but it isn’t. An SSH CA is something quite simple: all we need is an SSH key pair, and a few additional options for the ssh-keygen.