OpenSSH Certificates - A High Level View

Since release 5.6, OpenSSH (the ssh and sshd that most Unix derivatives use) has included support for certificates. These solve two problems:

Unknown Host

When you first connect to a remote host with ssh you see a message something like:

The authenticity of host '.... (....)' can't be established.
ECDSA key fingerprint is cb:37:20:d7:f0:94:09:8e:fa:cd:a1:b4:04:a2:4f:0c.
Are you sure you want to continue connecting (yes/no)? 

and - in theory - must then verify the hex digits. Which no-one does, of course. The end result is that you may connect to a computer that is lying about its identity, which is a problem.

This can be avoided, for a known set of hosts, with OpenSSH certificates.

On the hosts, the server keys must be signed by a “certificate authority”. This generates a certificate that includes the DNS name of the host.

On the clients, the user accounts must be configured to include (and use) the “CA certificate”.

Once this is done a client can connect to any of the hosts and the identity will be automatically confirmed. The message above will be shown only when connecting to a computer that is lying about its identity.

[Open question: Can the client be configured to refuse such hosts?]

One small limitation is that this is only possible for a finite number of machines. It will never work for “all” machines without the kind of infrastructure that we have today for HTTPS. But this is not an issue for the common use case where a client “out there” needs to connect back to machines at the “home” institution.

Revocation lists are also supported.

Password-less Connection

In the simplest case, each time that you connect to a host with ssh you need to answer your password.

There are two common ways to avoid this, both with issues. First, using ssh-agent means that you only need to do so once per “session”, but that still requires some typing and introduces other (small) risks. Second, you can copy your public key to the authorized_keys file on the remote host, but that means extra work for each host.

This can be avoided, for a known set of hosts, with OpenSSH certificates.

On the client, the user’s public key must be signed by a “certificate authority”. This generates a certificate that includes the account name(s) that can be connected to,

On the hosts, the server must be configured to include (and use) the “CA certificate”.

[I am trying to use the same phrasing as above to show the similarities between the two cases.]

Once this is done a client can connect without the need to enter a password. The work is less that copying public keys because it is only done once per user and per host (and not once for each combination of user and host).

Again, this is only possible for a limited number of accounts and machines.

References

Searching for “openssh certificates” turns up a couple of good, practical guides. This was great yesterday, but is down today; this one covers host authentication.


Related Posts

blog comments powered by