My current views on using OpenSSH with CA-based host and user authentication
Recent versions of OpenSSH have support for doing host and user
authentication via a local CA. Instead
of directly listing trusted public keys, you configure a CA and
then trust anything signed by the CA. This is explained tersely
primarily in the
ssh-keygen manpage and
at somewhat more length in articles like How to Harden SSH with
Identities and Certificates (via, via a comment by Patrick
here). As you might guess, I have some opinions on this.
I'm fine with using CA certs to authenticate hosts to users (especially
if OpenSSH still saves the host key to your
I haven't tested), because the practical alternative is no initial
authentication of hosts at all. Almost no one verifies the SSH keys
of new hosts that they're connecting to, so signing host keys and
then trusting the CA gives you extra security even in the face of
the fundamental problem with the basic CA model.
I very much disagree with using CA certs to sign user keypairs and authenticate users system-wide because it has the weakness of the basic CA model, namely you lose the ability to know what you're trusting. What keys have access? Well, any signed by this CA cert with the right attributes. What are those? Well, you don't know for sure that you know all of them. This is completely different from explicit lists of keys, where you know exactly what you're trusting (although you may not know who has access to those keys).
Using CA certs to sign user keypairs is generally put forward as a
solution to the problem of distributing and updating explicit lists
of them. However this problem already has any number of solutions,
for example using sshd's
AuthorizedKeysCommand to query a LDAP
directory (see eg this serverfault question).
If you're worried about the LDAP server going down, there are
workarounds for that. It's difficult for me to come up with an
environment where some solution like this isn't feasible, and such
solutions retain the advantage that you always have full control
over what identities are trusted and you can reliably audit this.
(I would not use CA-signed host keys as part of host-based
/etc/shosts.equiv. It suffers from exactly
the same problem as CA-signed user keys; you can never be completely
sure what you're trusting.)
Although it is not mentioned much or well documented, you can
apparently set up a personal CA for authentication via a
line in your
authorized_keys. I think that this is worse than
simply having normal keys listed, but it is at least less damaging
than doing it system-wide and you can make an argument that this
enables useful security things like frequent key rollover, limited-scope
keys, and safer use of keys on potentially exposed devices. If
you're doing these, maybe the security improvements are worth being
exposed to the CA key-issue risk.
(The idea is that you would keep your personal CA key more or less
offline; periodically you would sign a new moderate-duration encrypted
keypair and transport them to your online devices via eg a USB
memory stick. Restricted-scope keys would be done with special
ssh-keygen and then appropriate
requirements in your
authorized_keys on the restricted systems.
There are a bunch of tricks you could play here.)
Sidebar: A CA restriction feature I wish OpenSSH had
It would make me happier with CA signing if you could set limits
on the duration of (signed) keys that you'd accept. As it stands
right now, it is only
ssh-keysign with the CA that enforces any
expiry on signed keys; if you can persuade the CA to sign with a
key-validity period of ten years, well, you've got a key that's
good for ten years unless it gets detected and revoked. It would
be better if the consumer of the signed key could say 'I will only
accept signatures with a maximum validity period of X weeks', 'I
will only accept signatures with a start time after Y', and so on.
All of these would act to somewhat limit the damage from a one-time
CA key issue, whether or not you detected it.
Comments on this page:Written on 11 February 2016.