# Centralized OpenSSH Certificate Infrastructure ## The Certificate Authority and Management of Keys and Certificates. Prepare a secure box to host the OpenSSH Certificate Authority. It is recommended that the box does not run any other services, especially network-enabled ones. Create the CA key pair ssh-keygen -C "Foobar SSH CA" -f ca Generate key pairs for users: ssh-keygen -C "John Doe <john@foobar.com>" -f john ssh-keygen -C "Victor Sudakov <vas@foobar.com>" -f vas Sign the SSH key john.pub: - Assign the key identifier "johndoe" for logging and audit (the key identifier is logged by the server when the certificate is used for authentication). - The certificate will expire in 30 days. - The certificate is valid for the "tester" and "webmaster" principals. Principals serve for authorization on the SSH server (which local users the key's owner can login as). - The certificate serial number (-z) must be unique if Key Revocation Lists (KRLs) will be used. ssh-keygen -s ca -I johndoe -n webmaster,tester -V +30d -z 10 john.pub Sign the SSH key vas.pub: - Assign the key identifier "vas" for logging and audit (the key identifier is logged by the server when the certificate is used for authentication). - The certificate will never expire. - The certificate is valid for the "root" principal. Principals serve for authorization on the SSH server (which local users the key's owner can login as). - The certificate serial number (-z) must be unique if Key Revocation Lists (KRLs) will be used. ssh-keygen -s ca -I vas -n root -z 11 vas.pub Inspect the certificates before handing them out: ssh-keygen -L -f john-cert.pub ssh-keygen -L -f vas-cert.pub Hand out the key pairs (the files john\* and vas\*) securely to the respective users to be placed into their $HOME/.ssh/ directories. The users may wish to protect their key with a password. ## Configuration of SSH Servers Prepare the Access Control Matrix. The Matrix is a table of human users (their key identifiers) matched to principals (server users) they must be permitted to login as. In the table form, the Matrix may look like this: Real Name | Key Identifiers | Principals ----------|-----------------|------------ Victor S | vas | root John Doe | johndoe | webmaster,tester Copy the CA public key to the SSH server. Configure the server to trust it by adding the following lines to /etc/ssh/sshd_config TrustedUserCAKeys /etc/ssh/ca.pub RevokedKeys /etc/ssh/revoked-keys `touch /etc/ssh/revoked-keys` and reload sshd. ## Disabling Legacy User authorized_keys Support For the transitional period, it is suggested that both the new and the old authentication schemes work together in parallel. When all users receive their signed certificates, the support for authorized_keys files in users' home directories can be disabled by adding the following line to /etc/ssh/sshd_config AuthorizedKeysFile none and reloading sshd. ## Fine-grained Control over Principal Matching It may be necessary to implement more fine-grained control over principals to local usernames matching. For example, only a limited group of webmasters from a limited subset of networks should be permitted to login as "webmaster" to a specially protected server. This can be achieved with the AuthorizedPrincipalsFile directive in the /etc/ssh/sshd_config file. AuthorizedPrincipalsFile /etc/ssh/%u_principals The file /etc/ssh/webmaster_principals can be created on the SSH server with the following contents: from="172.17.2.0/23" webmaster_priv and the certificates for the limited group of webmasters should contain the "webmaster_priv" principal ("-n webmaster,webmaster_priv").