From efa094bae5f15055a22431cb20e79555144d6d33 Mon Sep 17 00:00:00 2001 From: Jameson Graef Rollins Date: Mon, 17 Nov 2008 14:56:38 -0500 Subject: [PATCH] Added new web page about server key signing. --- website/doc.mdwn | 6 +- website/getting-started-admin.mdwn | 2 + website/getting-started-user.mdwn | 7 +- website/signing-server-keys.mdwn | 131 +++++++++++++++++++++++++++++ 4 files changed, 144 insertions(+), 2 deletions(-) create mode 100644 website/signing-server-keys.mdwn diff --git a/website/doc.mdwn b/website/doc.mdwn index b60cf28..02b4184 100644 --- a/website/doc.mdwn +++ b/website/doc.mdwn @@ -8,6 +8,10 @@ * Getting started as a [user](/getting-started-user) * Getting started as a [server admin](/getting-started-admin) +## Going further ## + + * [Signing server keys](/signing-server-keys) + ## Under the hood ## * [Developing the monkeysphere](/community) @@ -15,7 +19,7 @@ ## References ## - * [Initial specifications at CMRG](http://cmrg.fifthhorseman.net/wiki/OpenPGPandSSH) + * [Initial Monkeysphere specifications at CMRG](http://cmrg.fifthhorseman.net/wiki/OpenPGPandSSH) * [OpenPGP (RFC 4880)](http://tools.ietf.org/html/rfc4880) * [Secure Shell Authentication Protocol (RFC 4252)](http://tools.ietf.org/html/rfc4252) * [URI scheme for SSH, RFC draft](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/) diff --git a/website/getting-started-admin.mdwn b/website/getting-started-admin.mdwn index 6c8ad53..1c373ac 100644 --- a/website/getting-started-admin.mdwn +++ b/website/getting-started-admin.mdwn @@ -7,6 +7,7 @@ so that your users can have it automatically verified, and you can set up your machine to automatically identify connecting users by their presence in the OpenPGP web of trust. + Server host key publication --------------------------- To generate and publish a server host key: @@ -48,6 +49,7 @@ effect. As with any change to `sshd_config`, be sure to retain an existing session to the machine while you test your changes so you don't get locked out. + Monkeysphere authorized_keys maintenance ---------------------------------------- diff --git a/website/getting-started-user.mdwn b/website/getting-started-user.mdwn index 5dcb0d6..9b04edc 100644 --- a/website/getting-started-user.mdwn +++ b/website/getting-started-user.mdwn @@ -20,6 +20,7 @@ done with a simple cronjob. An example of crontab line to do this is: This would refresh your keychain every day at noon. + Install the monkeysphere software on your system ------------------------------------------------ @@ -31,8 +32,9 @@ installed on your system. If you can't (or don't want to) upgrade to GnuTLS 2.6 or later, there are patches for GnuTLS 2.4 available in [the Monkeysphere git repo](/community). + Keeping your `known_hosts` file in sync with your keyring ------------------------------------------------------------ +--------------------------------------------------------- With your keyring updated, you want to make sure that OpenSSH can still see the most recent trusted information about who the various @@ -47,6 +49,7 @@ key for that host to the `known_hosts` file if one is found. This command could be added to a crontab as well, if desired. + Using `monkeysphere-ssh-proxycommand`(1) ---------------------------------------- @@ -91,6 +94,7 @@ 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. + Using your OpenPGP authentication key for SSH --------------------------------------------- @@ -105,6 +109,7 @@ you can feed your authentication subkey to your ssh agent by running: FIXME: using the key with a single ssh connection? + Establish trust --------------- diff --git a/website/signing-server-keys.mdwn b/website/signing-server-keys.mdwn new file mode 100644 index 0000000..151f975 --- /dev/null +++ b/website/signing-server-keys.mdwn @@ -0,0 +1,131 @@ +# Signing a server OpenPGP key # + +This page is meant to address the issue of signing server OpenPGP +keys. Server's are not people (or monkeys), obviously, so the +circumstances under which one should sign a server key is a big +different than those under which a person should sign another person's +key. + + +# Why are signatures on the server key important? # + +In order for users to connect to a server in a monkeysphere-enabled +network, the server key must have *full* validity for the connecting +user. If the user has not themselves signed the server's key, then +the server's key can only be valid if other people that the user +trusts have signed the key. + +If only one person has signed the server's key, then the user must +fully trust the single person who has signed the server key. Full +trust should be granted sparingly and with consideration, though, so +unless the user knows the server admin very well, they will in general +not have full trust of this person. + +However, full trust of the server key can also be achieved if the +server key has been signed by three or more people that the user has + *marginal* trust of. In other words, three or more *marginally* +trusted signatures equals one *fully* trusted signature. It is much +more common for users to have marginal trust of other users in the Web +of Trust. For this reason, it is important to have as many people +sign the server key as possible. + + +## What information should you have before signing a server key? ## + +When signing the key of a person, you want to do two things: + +1. verify the identity of the person. +2. verify that the person is actually in control of the key that you +are signing. + +For a server, you want to do basically the same thing: + +1. verify the identity of the server. +2. verify that the server is actually in control of the key that you +are signing. + +However, with a server, verifying these things is a little trickier. + +Verifying that the server is in control of the key is, in principle, +straightforward. If you are logged on to the machine in question, +then you can check directly that the key exists on the system. + +What is not so straightforward is what exactly it means to "verify the +identity" of a remote server on the web? The identity in this case is +the fully qualified domain name (FQDN) of the host. Verifying this +identity amounts to being sure that the host in question really is +located at that FQDN. + + +## Signing the server key ## + +If you are the person (or persons) that actually setup the server and +configured Monkeysphere and ssh on the server, then clearly you should +definitely sign the server key right away. When the server is first +setup, the persons who set it up are the only ones who can actually +vouch for the server key, so their signatures are necessary to get +things going. Their signatures are also necessary so that they can +verify the host key themselves and log into the server via +monkeysphere-enabled ssh in the future. + +If you did not set up the server initially, you do not have an +accumulated full trust of the person(s) who did, and you do not +necessarily have console access to the server directly, it's hard to +confidently verify the server identity and key ownership. You would +like to be able to walk up to the server, log in at the console, and +get the fingerprint of the ssh host key directly. But this is usually +untenable. + +However, it is still possible to verify the server identity *and* +server ownership of the key, even in this case. + + +## Remotely verifying server identify and key possession ## + +It is in fact possible to verify the identity and key ownership of a +server in one fell swoop with monkeysphere-enabled ssh. Here is the +procedure: + +> **Attempt to make a monkeysphere-enabled ssh connection to the host in +question. Monkeysphere will check that the ssh host key offered by the +host matches the OpenPGP key with the correct host FQDN user ID. If +the ssh host key and the OpenPGP key with the correct user ID match, +then you will have effectively:** + +>**1. verified the host identity, because you actually connected to the +host in question, which you know because you:** + +>**2. verified the host is in control of the key, because the ssh host +key offered by the host matches the OpenPGP key with correct host FQDN +user ID.** + +Here is an example: + + servo:~ 0$ ssh zimmermann.mayfirst.org + -------------------- Monkeysphere warning ------------------- + Monkeysphere found OpenPGP keys for this hostname, but none had full validity. + An OpenPGP key matching the ssh key offered by the host was found: + + pub 2048R/860E8F9C 2008-10-29 [expires: 2009-02-26] + uid [marginal] ssh://zimmermann.mayfirst.org + sig! 76CC057D 2008-11-15 Jamie McClelland + sig!3 860E8F9C 2008-10-29 ssh://zimmermann.mayfirst.org + sig! D21739E9 2008-10-29 Daniel Kahn Gillmor + sig! 1CF2D62A 2008-11-16 Micah Anderson + + RSA key fingerprint is 81:96:13:3e:24:c9:3c:5b:3c:6d:55:ba:58:85:e9:9e. + -------------------- ssh continues below -------------------- + The authenticity of host 'zimmermann.mayfirst.org ()' can't be established. + RSA key fingerprint is 81:96:13:3e:24:c9:3c:5b:3c:6d:55:ba:58:85:e9:9e. + No matching host key fingerprint found in DNS. + Are you sure you want to continue connecting (yes/no)? no + Host key verification failed. + servo:~ 255$ + +I have attempted to connect to the host zimmermann.mayfirst.org. +zimmermann's host key has only *marginal* validity for the FQDN user +ID in question, so I am not able to connect. However, the +monkeysphere has checked that the ssh host key actually does match the +OpenPGP key with the correct user ID `ssh://zimmermann.mayfirst.org`. +I have therefore verified the identity of zimmermann, and verified +that zimmermann is in possession of the key in question. -- 2.26.2