From a96625fb216143164f12191526939f4c0afcd5a9 Mon Sep 17 00:00:00 2001 From: mike castleman Date: Sat, 15 Nov 2008 18:23:14 -0500 Subject: rename --- website/bugs/useful-information.mdwn | 10 ---------- website/bugs/useful_information.mdwn | 10 ++++++++++ 2 files changed, 10 insertions(+), 10 deletions(-) delete mode 100644 website/bugs/useful-information.mdwn create mode 100644 website/bugs/useful_information.mdwn (limited to 'website') diff --git a/website/bugs/useful-information.mdwn b/website/bugs/useful-information.mdwn deleted file mode 100644 index 0750354..0000000 --- a/website/bugs/useful-information.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -I would like to know, at INFO (default) log level, when the -monkeyspehere makes a "real" modification to my known_hosts file; that -is, when it adds or deletes a key. - -Apparently this is hard because monkeysphere is currently configured to -delete all keys and then add good keys, so a key added for the first -time seems to the monkeysphere very similar to a key re-added ten -seconds after last login. - -Still, from a UI perspective, I want to know what monkeysphere is doing. diff --git a/website/bugs/useful_information.mdwn b/website/bugs/useful_information.mdwn new file mode 100644 index 0000000..0750354 --- /dev/null +++ b/website/bugs/useful_information.mdwn @@ -0,0 +1,10 @@ +I would like to know, at INFO (default) log level, when the +monkeyspehere makes a "real" modification to my known_hosts file; that +is, when it adds or deletes a key. + +Apparently this is hard because monkeysphere is currently configured to +delete all keys and then add good keys, so a key added for the first +time seems to the monkeysphere very similar to a key re-added ten +seconds after last login. + +Still, from a UI perspective, I want to know what monkeysphere is doing. -- cgit v1.2.3 From d056cc64effacd7936fddb6e696957868fff7eed Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Sun, 16 Nov 2008 02:39:51 -0500 Subject: feedback on useful-information bug. --- website/bugs/useful-information.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'website') diff --git a/website/bugs/useful-information.mdwn b/website/bugs/useful-information.mdwn index 0750354..62094bb 100644 --- a/website/bugs/useful-information.mdwn +++ b/website/bugs/useful-information.mdwn @@ -8,3 +8,17 @@ time seems to the monkeysphere very similar to a key re-added ten seconds after last login. Still, from a UI perspective, I want to know what monkeysphere is doing. + +------ + +It looks like jrollins committed a change for reporting at INFO level +when a host key gets added by the monkeysphere: +2459fa3ea277d7b9289945748619eab1e3441e5c + +When i connect to a host whose key is not already present in my +known_hosts file, i get the following to stderr: + + ms: * new key for squeak.fifthhorseman.net added to known_hosts file. + +This doesn't fully close this bug, because we aren't notifying on key +deletion, afaict. -- cgit v1.2.3 From 9751169042746ae5208edfb5c40ea62b30504735 Mon Sep 17 00:00:00 2001 From: Jameson Graef Rollins Date: Mon, 17 Nov 2008 12:05:05 -0500 Subject: add comment to bug about notification of modifications to known_hosts file. --- website/bugs/useful_information.mdwn | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) (limited to 'website') diff --git a/website/bugs/useful_information.mdwn b/website/bugs/useful_information.mdwn index 62094bb..dd0077a 100644 --- a/website/bugs/useful_information.mdwn +++ b/website/bugs/useful_information.mdwn @@ -1,5 +1,5 @@ I would like to know, at INFO (default) log level, when the -monkeyspehere makes a "real" modification to my known_hosts file; that +monkeyspehere makes a "real" modification to my known\_hosts file; that is, when it adds or deletes a key. Apparently this is hard because monkeysphere is currently configured to @@ -22,3 +22,19 @@ known_hosts file, i get the following to stderr: This doesn't fully close this bug, because we aren't notifying on key deletion, afaict. + +------ + +So current log level DEBUG will output a message if the known host +file has been modified. If the issue is that you want to know at the +default log level everytime the known\_hots file is modified, then we +should just move this message to INFO instead of debug, and then maybe +remove the message that I added above. I was under the impression +that the issue was more about notification that a *new* key was added +to the known\_hosts file, and therefore the new INFO message above +fixed that problem. Should we do this instead? + +In general, more verbose log levels *do* tell the user what the +monkeysphere is doing. Moving to DEBUG log level will tell you pretty +much everything that happens. I do *not* think that this should be +the default log level, though. -- cgit v1.2.3 From efa094bae5f15055a22431cb20e79555144d6d33 Mon Sep 17 00:00:00 2001 From: Jameson Graef Rollins Date: Mon, 17 Nov 2008 14:56:38 -0500 Subject: 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 (limited to 'website') 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. -- cgit v1.2.3 From b8a60a2c3c6e66513c1e4b83b65a2f808c882843 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Tue, 18 Nov 2008 00:48:47 -0500 Subject: further commentary on proxy_command logging. --- website/bugs/useful_information.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'website') diff --git a/website/bugs/useful_information.mdwn b/website/bugs/useful_information.mdwn index dd0077a..025d678 100644 --- a/website/bugs/useful_information.mdwn +++ b/website/bugs/useful_information.mdwn @@ -38,3 +38,13 @@ In general, more verbose log levels *do* tell the user what the monkeysphere is doing. Moving to DEBUG log level will tell you pretty much everything that happens. I do *not* think that this should be the default log level, though. + +------ + +I wouldn't want to see an extremely verbose default log level. But i +do think that saying something like "key blah blah blah was stripped +from your known\_hosts file because it was expired" (for example) +would be useful. I think this case would occur infrequently enough +that it is worth reporting in the UI at the regular log level. + + --dkg -- cgit v1.2.3 From 888c5cf2555732bcdadb214d19b5603b8d5dabed Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Tue, 18 Nov 2008 01:29:34 -0500 Subject: minor grammar/vocabulary nitpicking. --- website/signing-server-keys.mdwn | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) (limited to 'website') diff --git a/website/signing-server-keys.mdwn b/website/signing-server-keys.mdwn index 151f975..e0d26a7 100644 --- a/website/signing-server-keys.mdwn +++ b/website/signing-server-keys.mdwn @@ -1,19 +1,17 @@ # 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. - +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* 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. +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 @@ -26,13 +24,12 @@ 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 +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? ## -When signing the key of a person, you want to do two things: +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 @@ -51,10 +48,10 @@ 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. +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 ## -- cgit v1.2.3 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 +++++++++++++++++++++++++++++++++++++++ website/signing-server-keys.mdwn | 128 --------------------------------------- 2 files changed, 128 insertions(+), 128 deletions(-) create mode 100644 website/signing-host-keys.mdwn delete mode 100644 website/signing-server-keys.mdwn (limited to 'website') 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. diff --git a/website/signing-server-keys.mdwn b/website/signing-server-keys.mdwn deleted file mode 100644 index e0d26a7..0000000 --- a/website/signing-server-keys.mdwn +++ /dev/null @@ -1,128 +0,0 @@ -# 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