Using ssh keys to login to remote servers provides a huge improvement in security over password login [1]. However, it creates a new problem – managing those keys. This becomes a real problem when a developer has installed a public key on a number of remote hosts, then leaves company. There is no easy way to find out which servers have that public key in any ‘authorized_keys’ file, so that it can be removed to revoke access.

OpenSSH certificates provide a partial solution to that problem.

A certificate consist of the public part of the key-pair signed by a certificate authority. The certificate is made available next to the ssh private key; the ssh client presents the certificate to the remote host instead of the public key; the remote host verifies the certificate against the certificate authority public key, then provides access.

The certificate can be restricted in certain ways: it can prevent logging in (used for tunneling only); can force the connection to run a fixed command; can restrict the validity of the certificate to a range of dates; and so on.

This ability to automatically expire the certificate means that a developer who leaves the company automatically has access revoked after a certain period. However, it does mean that the certificates have to be renewed periodically.

The problem has changed from one of revoking access in an exceptional case (someone leaves the company) to one of ensuring continued access over a period of time (every 6 months or year when the certificates expire).

It is possible to set up a remote-management task (using something like Ansible) to update certificates automatically. However, it would be just as easy to set up a remote-management task to remove no-longer-authorized keys from any authorized_keys files when it becomes necessary.