User authentication with SSH certificates

For more information see:overview

Generate key pair
Generate 'keyfilename', and '':
Conform to a naming convention

/usr/bin/ssh-keygen -b 4096 -t rsa -C keyfilename -f keyfilename

Submit the .pub file to the appropriate authority.
Once the authority has published the signed certificate download it.
Store the certificate file in the same directory as your private key.

Load private key

ssh-add mangobiche_gituser

The certificate will also be loaded.

Enter passphrase for mangobiche_gituser:
Identity added: mangobiche_gituser (mangobiche_gituser)
Certificate added: (mangobiche_gituser)

Inspect a certificate file

ssh-keygen -L -f

The cerficate's principals indicates which accounts you can log into.
        Type: user certificate
        Public key: RSA-CERT SHA256:c3/EzgPsLQ7/Q1FgqU2kcc5bWHxO/Q23+/8RoRV1gxA
        Signing CA: RSA SHA256:AO/AHKV3hVcG/y5FztA4cvEQu2iDysFqPxXv2ZQ7srY
        Key ID: "id_tunnel_admin"
        Serial: 0
        Valid: from 2017-07-03T13:58:00 to 2018-07-02T13:59:17
        Critical Options: (none)


To access a remote host using SSH certificate user authentication you need to generate a key pair, then submit the public key to an authority that is trusted by that remote host.
The authority generates a signed certificate with your public key file and publishes it.
You download it and use it along with your private key.
No one can use a certificate without also having the private key.

When you load the private key into your ssh-agent the certificate is also loaded.
A certificate gains access to any account listed as principal in your certificate on any host that trusts the signing authority.
It eliminates the need to distribute your public key to each account on each host.

Naming convention

Use a naming convention for key filenames.

For example we implement the policy of using a different key pair on every host a user logs in from.
Our key filenames are always prefixed with the host name the key pair resides on, followed by a string that identifies the user and/or a string that indicates the range of uses of the key.
E.G. 'mangobiche_jsmith_gituser'

This makes it easier to identify which keys to revoke when a given host is compromised or when a given user has withdrawn from the group.
It also makes it easier to discern what is going on in the logs.


ssh-add fails to load certificate

On ubuntu the ssh-add utility fails to load certificate files. It occurs when the agent is the one implemented by gnome-keyring. The fix is to stop using the ssh component of gnome-keyring. Since the initialization process actually starts up a true ssh-agent and then launches gnome-keyring-ssh.desktop which clobbers AUTH_SOCKET to take it over, we can revert back to the original ssh-agent by disabling gnome-keyring-ssh.desktop.

Disable gnome-keyring-ssh.desktop:

cd /etc/xdg/autostart/
sudo emacs gnome-keyring-ssh.desktop

Add the following line to the desktop file and save it, then reboot:


ssh -i -o CertificateFile fails to match certificate

If instead of using ssh agent to load certificates, you specify it on the command line as in the following example, the certificate fails to load:

ssh -i mangobiche_gituser -o

As a workaround I have found that renaming the certificate file from to and invoking ssh as follows will work:

ssh -i mangobiche_gituser -o