From d89e9293654cfd6330e2aa398768eca0fc8fa621 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Tue, 18 Nov 2008 01:30:32 -0500 Subject: renaming page about signing host keys. --- website/signing-host-keys.mdwn | 128 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 website/signing-host-keys.mdwn (limited to 'website/signing-host-keys.mdwn') diff --git a/website/signing-host-keys.mdwn b/website/signing-host-keys.mdwn new file mode 100644 index 0000000..e0d26a7 --- /dev/null +++ b/website/signing-host-keys.mdwn @@ -0,0 +1,128 @@ +# Signing a server OpenPGP key # + +This page is meant to address the issue of signing server OpenPGP +keys. Servers are not people, so the circumstances under which one +should sign a server key are different from those under which one +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* calculated validity from the +perspective of 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 advisable to have as many people +sign the server key as possible. + +## What information should you have before signing a server key? ## + +Before 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 internet? 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. -- cgit v1.2.3 From b399dbcddb7bce2cfe9a470a019fc58165793b6e Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Tue, 18 Nov 2008 01:40:28 -0500 Subject: changing terminology from server key to host key --- website/signing-host-keys.mdwn | 59 +++++++++++++++++++++--------------------- 1 file changed, 29 insertions(+), 30 deletions(-) (limited to 'website/signing-host-keys.mdwn') diff --git a/website/signing-host-keys.mdwn b/website/signing-host-keys.mdwn index e0d26a7..1eb61a0 100644 --- a/website/signing-host-keys.mdwn +++ b/website/signing-host-keys.mdwn @@ -1,25 +1,25 @@ -# Signing a server OpenPGP key # +# Signing a host's SSH key using OpenPGP # -This page is meant to address the issue of signing server OpenPGP -keys. Servers are not people, so the circumstances under which one -should sign a server key are different from those under which one +This page is meant to address the issue of signing OpenPGP-based SSH +host keys. Machines are not people, so the circumstances under which +one should sign a host key are different from those under which one should sign another person's key. -# Why are signatures on the server key important? # +# Why are signatures on an SSH host key important? # -In order for users to connect to a server in a monkeysphere-enabled -network, the server key must have *full* calculated validity from the -perspective of 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. +In order for users to validate a host (an SSH server) in a +monkeysphere-enabled network, the host key must have *full* calculated +validity from the perspective of 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. +fully trust the single person who has signed the host 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 +However, full trust of the host 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 @@ -27,7 +27,7 @@ more common for users to have marginal trust of other users in the Web of Trust. For this reason, it is advisable to have as many people sign the server key as possible. -## What information should you have before signing a server key? ## +## What information should you have before signing a host key? ## Before signing the key of a person, you want to do two things: @@ -41,9 +41,10 @@ For a server, you want to do basically the same thing: 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. +However, verifying these things for a server is less intuitive than it +is for a human. -Verifying that the server is in control of the key is, in principle, +Verifying that the host 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. @@ -53,16 +54,15 @@ 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 ## +## Signing the host 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 +configured Monkeysphere and ssh on the server, then you should sign +the host key as part of that process. When the server is first set +up, the administrators 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 validate 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 @@ -71,13 +71,12 @@ 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. +impossible. 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 ## +## Remotely verifying host identity 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 @@ -122,7 +121,7 @@ Here is an example: 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 +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. -- cgit v1.2.3