This site is now 100% read-only, and retired.

Publishing host services to OpenPGP with Monkeysphere

Posted by drgraefy on Wed 20 Oct 2010 at 10:22

The Monkeysphere Project aims to put authentication on the web back into the hands of web users through the use of the OpenPGP Web of Trust (WoT). Instead of purchasing certifications from the certificate authority cartel, or offering uncertified keys for services, admins can use the Monkeysphere tools to make OpenPGP certificates for their services, publish the certificates to the WoT, and then certify it themselves.

Users can use the Monkeysphere client tools to validate the service certificates, or present users with useful info about who as certified a service. Using Monkeysphere for authentication brings in all the benefits of OpenPGP, such as certificate revocation, expiration, ease of rekeying, etc. Monkeysphere currently supports ssh and https, but the project hopes to expand to as many protocols as possible.

This is the first in a series of articles about how to use the Monkeysphere tools for authentication on the web. In this article, we describe how an admin can publish OpenPGP certifications for their site services, allowing their users to validate their services through the OpenPGP Web of Trust.

Getting the monkeysphere tools

The Monkeysphere tools are of course available in Debian. Version 0.31 is available in squeeze and lenny backports:

# aptitude install monkeysphere

Generating host service certificates

The first step is to create an OpenPGP certificate for your service. This is done with the monkeysphere-host import-key command, which takes an RSA key and service ID for the service, and then generates a new OpenPGP certificate for the service that is maintained in a system gpg keyring.

For instance, for ssh, the command might look something like this:

# monkeysphere-host import-key /etc/ssh/ssh_host_rsa_key ssh://

This will generate an OpenPGP certificate for the server based on the ssh host RSA key, where the primary user ID for this certificate is the ssh service URI for the host (e.g. ssh:// Remember that the name you provide here should probably be a fully qualified domain name for the host in order for your users to find it.

For https, you would provide the RSA key used for your site's existing X.509 certificate, if you have one, or you can use the 'snakeoil' cert provided with many distributions:

# monkeysphere-host import-key /etc/ssl/private/ssl-cert-snakeoil.key

Once you have created service OpenPGP certificates, you can display information about them with the show-keys command:

# monkeysphere-host show-keys
pub   1024R/ABCDEF19 2009-05-07
ssh fingerprint: 1024 a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1 (RSA)

Once your host keys have been generated, you'll probably want to publish them to the public keyservers which distribute the Web of Trust with the publish-keys command:

# monkeysphere-host publish-keys

Signing host service certificates

However, anyone could publish a simple self-signed certificate to the WoT with any name attached, including your servers. Your users should be able to tell that someone they know and trust with the machine (e.g. you, the administrator) has verified that this particular key is indeed the correct key. So your next step is to sign the host's key with your own OpenPGP key and publish that signature.

On your (the admin's) local machine retrieve the host key (it may take several minutes for the key to propagate across the keyserver network), and sign it:

$ gpg --search '=ssh://'
$ gpg --sign-key '=ssh://'

Make sure you compare the fingerprint of the retrieved certificate with the output from the 'show-key' command above!

Next, find out the host key's Key ID, which is a hexadecimal string like "ABCDEF19":

$ gpg --list-keys '=ssh://'

which will output something like:

pub   1024R/ABCDEF19 2009-05-07
uid       [  full  ] ssh://

Finally, publish your signatures back to the keyservers, so that your users can automatically verify your machine when they connect:

$ gpg --send-key ABCDEF19

You can encourage your users to sign the service keys as well. This helps strengthen the WoT, and helps other users have certifiable paths to your services. Check out this discussion about signing service keys.

Host key management

The monkeysphere-host command provides a bunch of commands that help the admin manage their host keys:

  • add-servicename allows you to add new service names to an existing key.
  • add-revoker allows you to add a separate key that can have the authority to revoke the service key.
  • revoke-key allows you to generate a revocation certificate for a host key.


We hope we've demonstrated that it's surprisingly easy to publish service key in the WoT. Monkeysphere particularly nice for sites that want to offer secure services, but don't want to go through the hassle and expense of purchasing certifications from the CA cartel (hint hint!). A lot more information can be found on the Monkeysphere Project home page, and in the project documentation.

If you're interested in seeing other protocols supported, or in contributing in any way, please get involved!

In future articles, we'll discuss how to use the Monekysphere client tools for ssh and Iceweasel to verify services, and how to handle sshd user authentication with Monkeysphere.



Re: Publishing host services to OpenPGP with Monkeysphere
Posted by banchieri (2a01:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 20 Jan 2011 at 00:19
[ View Weblogs ]

Interesting. Sounds like a good idea to combine OpenPGP/GnuPG's "web of trust" model with the PKI model: Instead of a self-signed "snakeoil" service certificate, register your self-signed CA certificate with Monkeysphere and have your whole certificate chain trusted. Moreover, that would solve the problem of currently unsupported services.

[ Parent ]

Re: Publishing host services to OpenPGP with Monkeysphere
Posted by dkg (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Fri 21 Jan 2011 at 00:12
[ View Weblogs ]
Yep, that's exactly the idea. There's no reason that we need to be blocked by the problematic single-issuer model of X.509, or by the cartel of certificate authorities that currently profit from it. And we can phase in the distributed model without requiring that people drop their existing X.509 certificates if they don't want to.

[ Parent ]