Monkeysphere SSH user authentication (monkeysphere-authentication)

A host can maintain ssh-style authorized_keys files automatically for its users with the Monkeysphere. This frees you (the administrator) from the task of manually checking/placing SSH keys, and enables users to do relatively painless key transitions, and to quickly and universally revoke access if they find that their ssh key has become compromised.

You simply tell the system what person (identified by her OpenPGP User ID) should have access to an account, the Monkeysphere takes care of generating the proper authorized_keys file and keeping it up-to-date, and sshd reads the generated authorized_keys files directly.

Monkeysphere authorized_keys maintenance

For each user account on the server, the userids of people authorized to log into that account would be placed, one per line, in:


For example, this file could contain:

Joe User <>
Joe User at Work <>

Provided that those exact strings are among the uids for which the user's gpg key is valid.

The server will use the Monkeysphere to look up matching OpenPGP certificates, validate them, and generate an authorized_keys file.

To validate the OpenPGP certificates, the server needs to know who it can trust to correctly identify users. The individuals trusted to identify users like this are known in the Monkeysphere as "Identity Certifiers". One obvious choice is to trust you, the administrator, to be an Identity Certifier.

You will need to know your full 40 hex character gpg fingerprint. This can be learned by doing:

gpg --with-colons --fingerprint

Replacing "" with either your gpg key id, or your gpg uid. The output of this command is very long and difficult to read. Look for a line like:


The portion between the ":::::::::" and ":" is your 40 digit fingerprint.

With your OpenPGP 40-digit hex fingerprint replacing $GPGFPR, then run the following command on the server:

# monkeysphere-authentication add-identity-certifier $GPGFPR

You'll probably only set up Identity Certifiers when you set up the machine. After that, you'll only need to add or remove Identity Certifiers when the roster of admins on the machine changes, or when one of the admins switches OpenPGP keys.

Now that the server knows who to trust to identify users, the Monkeysphere can generate ssh-style authorized_keys quickly and easily:

To update the Monkeysphere-generated authorized_keys file for user "bob", run:

# monkeysphere-authentication update-users bob

To update the monkeysphere authorized_keys file for all users on the the system, run the same command with no arguments:

# monkeysphere-authentication update-users

You probably want to set up a regularly scheduled job (e.g. with cron) to do this automatically.

Update OpenSSH server AuthorizedKeysFile configuration

Generating the authorized_keys files is not quite enough, because sshd needs to know where to find the generated keys.

With OpenSSH 5.9 or later, you can do this by adding an extra path to the AuthorizedKeysFile directive in /etc/ssh/sshd_config.

AuthorizedKeysFile %h/.ssh/authorized_keys /var/lib/monkeysphere/authorized_keys/%u

Warning: When using the above configuration it is recommended to change the MONKEYSPHERE_RAW_AUTHORIZED_KEYS environment variable from its default value to none (or put RAW_AUTHORIZED_KEYS=none in /etc/monkeysphere/monkeysphere-authentication.conf), as this will avoid unnecessary duplication of SSH keys.

Older version of OpenSSH (5.8 and earlier) do not support specifying multiple paths in AuthorizedKeysFile, so you need to comment out the existing one and add the following line.

AuthorizedKeysFile /var/lib/monkeysphere/authorized_keys/%u

Warning: Be aware that with this change in configuration, only those users whose authorized keys files appear under the above path will be able to log in via ssh. This includes the root user if root has ssh access. Remember to run 'monkeysphere-authentication update-users' if you are unsure whether any users' authorized_keys files have been updated.

You'll need to restart sshd to have your changes take effect. As with any change to sshd_config, if you're doing this remotely, be sure to retain an existing session to the machine while you test your changes so you don't get locked out if something went wrong.