OpenSSH – Docs for CA-Based Certificate Authentication

certificate-authorityssh

OpenSSH 5.4 added a new method for certificate authentication (changes).

 * Add support for certificate authentication of users and hosts using a
   new, minimal OpenSSH certificate format (not X.509). Certificates
   contain a public key, identity information and some validity
   constraints and are signed with a standard SSH public key using
   ssh-keygen(1). CA keys may be marked as trusted in authorized_keys
   or via a TrustedUserCAKeys option in sshd_config(5) (for user
   authentication), or in known_hosts (for host authentication).

   Documentation for certificate support may be found in ssh-keygen(1),
   sshd(8) and ssh(1) and a description of the protocol extensions in
   PROTOCOL.certkeys.

Is there any guides or documentation beyond what is mentioned in the ssh-keygen man-page? The man page covers how to generate certificate and use them, but it doesn't really seem to provide much information about the certificate authority setup. For example, can I sign the keys with an intermediate CA, and have the server trust the parent CA?

This comment about the new feature seems to mean that I could setup my servers to trust the CA, then setup a method to sign keys, and then users would not have to publish their individual keys on the server. This also seems to support key expiration, which is great since getting rid of old/invalid keys is more difficult then it should be. But I am hoping to find some more documentation about describe the total configuration CA, SSH server, and SSH client settings needed to make this work.

Best Answer

Indeed, the docs do look rather sparse. The PROTOCOL.certkeys file is probably your best place to go for low-level documentation re: this feature.

re: using intermediate CA's, have a look at this quote from that doc:

"Chained" certificates, where the signature key type is a certificate type itself are NOT supported.

If I'm reading that right then using an intermediate CA is expressly not possible. In general, it looks like this is a really, really bare-bones PKI implementation and you should probably throw out most of what you'd expect in an X.509 PKI world.