For more information see:overview
Generate key pair
Generate 'keyfilename', and 'keyfilename.pub':
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
The certificate will also be loaded.
Enter passphrase for mangobiche_gituser: Identity added: mangobiche_gituser (mangobiche_gituser) Certificate added: mangobiche_gituser-cert.pub (mangobiche_gituser)
Inspect a certificate file
ssh-keygen -L -f id_tunnel_admin-cert.pub
The cerficate's principals indicates which accounts you can log into.
id_tunnel_admin-cert.pub: Type: email@example.com 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 Principals: tunneladmin relay Critical Options: (none) Extensions: permit-X11-forwarding permit-agent-forwarding permit-port-forwarding permit-pty permit-user-rc
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.
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.
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.
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 CertificateFile=mangobiche_gituser-cert.pub firstname.lastname@example.org
As a workaround I have found that renaming the certificate file from mangobiche_gituser-cert.pub to mangobiche_gituser.pub and invoking ssh as follows will work:
ssh -i mangobiche_gituser -o CertificateFile=mangobiche_gituser.pub email@example.com