Advanced usage of the Monkeysphere with SSH

Managing your SSH identity through the Web of Trust

You've already got an OpenPGP identity in the Web of Trust. But you probably don't currently use it to identify yourself to SSH servers.

To do that, you'll need to add an authentication-capable subkey to your OpenPGP identity. You can do that with:

$ monkeysphere gen-subkey

If you have more than one secret key, you'll need to specify the key you want to add the subkey to on the command line.

Since this is a change to your key, you probably want to re-publish your key to the public keyservers. If your key ID is $GPGID:

$ gpg --keyserver pool.sks-keyservers.net --send-key $GPGID

This way, remote services that use the monkeysphere for user authentication will know about your SSH identity.

You may need to wait a few minutes for your new key to propagate around the keyserver network, and another little while for any remote host running the monkeysphere to pick up the new subkey.

Using your OpenPGP authentication key for SSH via ssh-agent(1)

Once you have created an OpenPGP authentication subkey, you will need to feed it to your ssh-agent. Your agent can then manage the key for all of your ssh sessions.

First make sure you have an agent running:

$ ssh-add -l

Then hand off the authentication subkey to the agent:

$ monkeysphere subkey-to-ssh-agent

You can supply normal ssh-add(1) flags to this command if you want to give the agent different instructions. For example, if you want the agent to always ask for confirmation before using this key, you should do this instead:

$ monkeysphere subkey-to-ssh-agent -c

You can verify that the key is in the agent just as you normally would:

$ ssh-add -l

Now you can connect to hosts that use the monkeysphere for user authentication using that key:

$ ssh server.example.net

Using your OpenPGP authentication key for SSH without the agent

Currently, the monkeysphere does not support using your SSH subkey without the ssh-agent :( It's not impossible, we just haven't gotten around to it yet. Patches are welcome!

If you are not running an agent, and you just want a single session with the key, you could cobble something together a one-shot agent like this:

$ ssh-agent sh -c 'monkeysphere subkey-to-ssh-agent && ssh server.example.net'

Keep your SSH identity up-to-date

If your SSH identity or your whole OpenPGP keyring is compromised, you should be sure to revoke it and publish the revocations to the keyserver. If only your SSH identity was compromised, you should just revoke the authentication subkey. For keys with small sizes, or which may have been otherwise compromised, you may wish to simply revoke the old authentication subkey, add a new one, and publish those changes to the public keyservers together.

Many people believe that it is good security practice to only use asymmetric keys (such as the RSA keys used by SSH and the Monkeysphere) for a limited period of time, and prefer to transition from key to key every year or two.

Without the monkeysphere, you would have needed to update your authorized_keys file on every host you connect to in order to effect such a transition. But all hosts that use the Monkeysphere to generate their authorized keys files will transition automatically to your new key, if you publish/revoke as described above.

User-maintained authorized_keys files with the Monkeysphere

Users can also maintain their own ~/.ssh/authorized_keys files with the Monkeysphere directly. This is primarily useful for accounts on hosts that are not already systematically using the Monkeysphere for user authentication. If you're not sure whether this is the case for your host, ask your system administrator.

If you want to do this as a regular user, use the update-authorized_keys command:

$ monkeysphere update-authorized_keys

This command will take all the user IDs listed in the ~/.monkeysphere/authorized_user_ids file and check to see if there are acceptable keys for those user IDs available. If so, they will be added to the ~/.ssh/authorized_keys file.

You must have indicated reasonable ownertrust in some key for this account, or no keys will be found with trusted certification paths.

If you find this useful, you might want to place this command in your crontab so that revocations and rekeyings can take place automatically.