One interesting new feature in OpenSSH that has been delivered in releases starting last year is Certificate Authority support. This is a very useful and easy to implement option in OpenSSH with the small difficulty that it is very new and is very difficult to find documentation for. The purpose of this document is to show an example of setting up Certificate Authority keys, to show how easy this process is, and to help provide some helpful documentation.
Traditional OpenSSH has long supported the creation of public/private keypairs that can be used to log in to individual accounts. The main feature of this is that the public part of each individual key must be copied to each server you wish to log into. This can become somewhat of an administrative/accounting burden. The new Certificate Authority (CA) feature alleviates this problem by allowing the administrator to copy a single CA key to each box, which will then allow any individual key which is signed by the CA to log into the box. This vastly simplifies administration of the individual boxes.
The CA feature can be used for both user authentication and host authentication. This blog post will give an example of user authentication. The host authentication can be set up in a very similar way, see the included references for specific examples. Host authentication is useful to ensure that all hosts authenticity can be verified without having to accept individual host keys. Everybody who uses ssh is familiar with the "The authenticity of host 'ABC (10.0.0.2)' can't be established." prompt that you get when logging into a machine for the first time, and CA host key usage can be used to eliminate this message.
The first thing to do is to set up your CA key. This is created just like any normal ssh key, using the ssh-keygen command, using any of the same options you use for a normal key.
Create your certificate authority:
$ ssh-keygen -f user-ca-key
Set up your server to trust the ca-key. You can do this at the individual account level, or at a server-wide level.
(individual account): to let any key signed by your CA log into one specific account, you can use the existing ~/.ssh/authorized_keys file. You simply drop in the CA public key, but prefix it with the "cert-authority" directive. Here is how you can do that with one command:
$ echo "cert-authority $(cat user-ca-key.pub)" >> ~/.ssh/authorized_keys
(server wide) To let user keys signed by your CA key log into any(*) account on the system, simply add the line, "TrustedUserCAKeys /etc/ssh/user-ca-key.pub" to your /etc/ssh/sshd_config file, then copy the user-ca-key.pub file to /etc/ssh/ on the server. (*) When you sign the individual keys with your CA key, you can specify a list of accounts that key is allowed to log into, so you can control which users can log into which accounts.
(optional) create a normal user key if you dont already have one. This follows the normal process for creating keys, and you can use any existing key you may already have. NOTE: now that we are logging in with CAs, we no longer need to copy the public key to the server, which is the whole point of this exercise.
$ ssh-keygen -f random-user-key
Sign the user key using the CA key.
$ ssh-keygen -s user-ca-key -I "Bob User's key" -n bob_user,bob -V +52w /path/to/id_rsa.pub
Notes: (1) when you sign the user key, you specify the accounts this key can access using the "-n" option. Use the "-I" option to specify user details. (2) When you sign the user key, eg. id_rsa.pub, it will create a separate certificate file called id_rsa-cert.pub that is used by the ssh client to log in.
Now you can use the user key to log into the server. The ssh client program will automatically use the -cert.pub files it finds to send certificate information to the server.
The new certificate authority key must be protected with a passphrase and kept in a secure location. If any third party obtains this key, they can get unlimited access to any machine using the CA.
Certificate Authorities are traditionally thought of as multilevel entities, where a toplevel authority signs individual certs, which can then be turned around to sign sub-entity certs. The implementation in OpenSSH does not currently support a multi-level CA structure, which can limit the potential use-cases.
Additionally, this feature uses existing ssh key formats, meaning it isnt a traditional SSL, x509 or other format CA key. This is also a benefit, because you dont have to worry about the complicated commands necessary to create those other format keys.
The other main limitation of this feature is that both the server and the client ssh versions must be at version 5.4 or higher. None of the enterprise linux versions (Red Hat, SUSE, etc) that I have checked have this version yet, so you have to manually upgrade your systems. Most of the client distributions, such as Fedora, have the requisite versions in their latest releases.
References: http://blog.habets.pp.se/2011/07/OpenSSH-certificates http://www.gossamer-threads.com/lists/openssh/users/50165 http://serverfault.com/questions/264515/how-to-revoke-an-ssh-certificate-not-ssh-identity-file