User authentication with SSH certificates
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
ssh-add mangobiche_gituser
The certificate will also be loaded.
output:
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
output:
The cerficate's principals indicates which accounts you can log into.
id_tunnel_admin-cert.pub:
Type: ssh-rsa-cert-v01@openssh.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
Overview
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.
Issues
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:
X-GNOME-Autostart-enabled=false
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 gituser@kiwi.bernatchez.net
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 gituser@kiwi.bernatchez.net