800 Signed SSH keys/certificates

Posted Almost 4 years ago. Visible to the public.


Signed SSH keys/certificates are a way for our customers to securely manage access to our application servers for an arbitrary number of users without need to ask Makandra Operations for each individual change.

If you are using Capistrano you have to check your Ruby version (>=2 and >=net-ssh-4.1 Show archive.org snapshot ) and which encryption algorithm you're using as there are certain limitations.

Algorithm State/Working
rsa Working
ecdsa Working
ed25519 Not Implemented Show archive.org snapshot

This setup describes three parties:

  1. Makandra
  2. an admin on customer side
  3. one or multiple users.

Our goal as Makandra is to keep your environment safe. Admins have the power to grant or revoke SSH access to servers. Users are actual developers, operation engineers or even automated processes that need access for specific tasks. These tasks may be limited in time and vary their scope. Both those details are probably best known to admins on customer side, making customer managed SSH access a viable option.


As a first step, the admin needs to create a CA key.

ssh-keygen -f ca

This will create two corresponding files: ca and ca.pub. The ca.pub should be sent to Makandra like a normal pubkey but with a note that this is part of a CA key pair that is used to sign additional SSH keys. The ca file should be kept safe and should generally only be accessible to the admin. This is the only step that includes communication with Makandra - afterwards you are able to manage access to application servers completely on your side.

The second step can be repeated for every user that wants access.

The user creates their personal private/public keypair as usual or may use an already existing key pair.
The user then sends the pubkey user.pub to the admin.
The admin signs the key.

ssh-keygen -s ca \
    -I "<identifier of the user, will be visible in the logs>" \
    -V -5m:+1w # from 5 minutes ago until now in 7 days \

This command creates a new file user-cert.pub which needs to be send back to the user.
We recommend that the -I and -V options should be set. The -I option is used to distinguish the logins in log files. The validity option -V specifies how long the signed key should be usable. We recommend to set it as short as needed and create a new cert if it expires.

The user can place this signed public key in the usual folder together with the private key (usually /home/$user/.ssh/). With this new public key the user is now able to connect to the server:

ssh server.domain.tld


Currently we do not support key revocation.
Nevertheless you can generate a new ca keypair and send us the public key with the request to replace the old key. This will invalidate all your existing signed certificates. The use of small timeframes of key validity should reduce the need to revoke signed certificates.


The most involved part of this process is on the side of the admin. Managing of a lot of keys can get complicated/exhausting without proper tools. But to start using the features these tools are not needed. We have no special recommendation and suggest to look into these once the need arises.

There are services/tools available for the admin to choose from:

Stefan Langenmaier
Last edit
About 3 years ago
Stefan Langenmaier
Source code in this card is licensed under the MIT License.
Posted by Stefan Langenmaier to opscomplete (2019-06-24 13:10)