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 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 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') 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 From 489006a448bff91a36378bf1917e630994a8fe87 Mon Sep 17 00:00:00 2001 From: Jameson Graef Rollins Date: Tue, 18 Nov 2008 01:59:50 -0500 Subject: update link in docs. --- website/doc.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'website') diff --git a/website/doc.mdwn b/website/doc.mdwn index 02b4184..cd7bc76 100644 --- a/website/doc.mdwn +++ b/website/doc.mdwn @@ -10,7 +10,7 @@ ## Going further ## - * [Signing server keys](/signing-server-keys) + * [Signing host keys](/signing-host-keys) ## Under the hood ## -- cgit v1.2.3 From f3e2dfe4463e234ed023fdf06ca019273f1597d5 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Fri, 28 Nov 2008 21:01:29 -0500 Subject: added release note for 0.22-1 --- website/download.mdwn | 36 ++++++++++++++++++------------------ website/news/release-0.22-1.mdwn | 25 +++++++++++++++++++++++++ 2 files changed, 43 insertions(+), 18 deletions(-) create mode 100644 website/news/release-0.22-1.mdwn (limited to 'website') diff --git a/website/download.mdwn b/website/download.mdwn index 6d5a73f..a5c7479 100644 --- a/website/download.mdwn +++ b/website/download.mdwn @@ -75,38 +75,38 @@ For those that would like to download the source directly, [the source is available](/community) via [git](http://git.or.cz/). The [latest -tarball](http://archive.monkeysphere.info/debian/pool/monkeysphere/m/monkeysphere/monkeysphere_0.21.orig.tar.gz) +tarball](http://archive.monkeysphere.info/debian/pool/monkeysphere/m/monkeysphere/monkeysphere_0.22.orig.tar.gz) is also available, and has these checksums: 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
-checksums for the monkeysphere 0.21 release:
+checksums for the monkeysphere 0.22 release:
 
 MD5:
-15fe181983565aca0fbe4c41f9f6752e  monkeysphere_0.21.orig.tar.gz
+2bb00c86323409b98aff53f94d9ce0a6  monkeysphere_0.22.orig.tar.gz
 
 SHA1:
-27e915a45cdbe50a139ed4f4b13746b17c165b0f  monkeysphere_0.21.orig.tar.gz
+312882ad192b8e7303e3e0ac9db20ac8ddc529b3  monkeysphere_0.22.orig.tar.gz
 
 SHA256:
-1535c3f722f5f5c1646a4981efef4a262ac7b23bf4b980c9aee11af2600eedc2  monkeysphere_0.21.orig.tar.gz
+2566facda807a67a4d2d6de3833cccfa0b78b454909e8d25f47a235a9e621b24  monkeysphere_0.22.orig.tar.gz
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (GNU/Linux)
 
-iQIVAwUBSR8+7BjmZ/HrivMUAQLeKg/+JT4LCXBR/06p/w2KBd1MKqch5Qf2ryIo
-mxCTWtZRgVQSeOFUJ5SXX+Tfs7VZfkV5HuahUH3NmGC6EMhYyB2olwBOOoIAqEKw
-1zVyn49bowCee+gTc3QHyT0Eqgt2ARtzl3/VrHkiw2MaJN3IZXseovyL8ksnEu+u
-s8fq26imtBrrucIxp4ZtHUw/h/YrJohHcJ8QQN5/UWFLug4C4aRFmnzL+oCySxAa
-0au/zFxxRZE5pMhLUvRwwCwPFx2CGBz6y9lAOiDPhhUqh+Bf7JKWJzk35Dj5Tm+2
-lCIzYtfpBkuF9ehCrm8WYF5aFg+gto8Bc6IJci9J6h2npBYIG0IbWOknMZz3+Ti2
-c3EltlJjK0LKEHujDYjf9tkNAxbBdtlYuw8x925ILeK7n8xX0Jr1TDzPyAIYaogv
-IVqsgnvQ489K8k06173kyrPaetyvOlU3bN1zcPdqTyCD6+eBbeCeKXO4324C8iMF
-rQPW4HScOdIidqFuzHyIT7PoY4DwWMgeAVymRSEufifvRcdCvQdlC4MaxxVf5I8A
-ATkD3CrY+5NZeERAGbmlu7Uz+sUk5tLUH0Q2qvjZUIQRctfr4BMheuBubsLR9yP3
-FZ4Q4kl34eU/WU7NtTmIFy7gDhLSIoeQINfYZlNEXQ7Y/RZUOEwoPI/spAXgw6De
-Xpsw0wPZtcM=
-=JDaA
+iQIVAwUBSTCiPRjmZ/HrivMUAQLg/BAAsdLsCQYSmvYLrYy1HiARtZOckqSOFv5e
+lnoOYEXKCXVjKqYUn4gjOkP2kQlnEOazfXrT/pO4u0AKUbf3C8bPDpIeao8uuPXI
+GG6HOWtsY93a2g8DM9fOzadIwhhBc9U7VwizBwFsxMw6xFTIKfoqqQonfEYFFLb6
+zyJVcfhmmGjgoJ9qA3AlYAf/i3Y/fcXh+YMI5J3Gez3BTVcep41UlcQUyd33pHF6
+aHdSWCzrotFual3fbf0meQewbBCW3JRBsbmCHQltbO/kNrtyfXb3Rp4oLiffcmpI
+DhfpFeonVHnUI9CVHmL7qbnBsgu5Q8l8Fxzu5pyzrGJxlvqBCpG8JM2FI0jJxw6o
+LQkmXCHteYKyopqKz5X0ATCot2Eoc9+kNEHwNWI37XbY7AV1XOOzGiaMjl+w8aUR
+QM8+Gi0h7SU2KuEogIsq1TghsDp3BJpTyBnc72ttLt2BvMzANOJnM8cmQqW8bOpz
+9Jdob+ISKkKG9q0wp61gb+8/f7mZKNtpr2rpRVYyjHgwR5XfbnS+gaD2B1NyG7NY
+yxW7fHpTsuwqcm2ONjZCDpEj0bXM0cL7r8c3J0L5kRCiN05c/KKYTNC70kTwCeQa
+ninihvIJal0Wu3LZxtYmtxuApq3wmc8NPo66C+TC24YGtxxJuZMS1qOlPFIPADIa
+EeBVdDmRbBw=
+=FmCP
 -----END PGP SIGNATURE-----
diff --git a/website/news/release-0.22-1.mdwn b/website/news/release-0.22-1.mdwn new file mode 100644 index 0000000..078b605 --- /dev/null +++ b/website/news/release-0.22-1.mdwn @@ -0,0 +1,25 @@ +[[meta title="Monkeysphere 0.22-1 released!"]] + +Monkeysphere 0.22-1 has been released. + +Notes from the changelog: + +
+  * New upstream release:
+  [ Jameson Graef Rollins ]
+
+    - added info log output when a new key is added to known_hosts file.
+    - added some useful output to the ssh-proxycommand for "marginal"
+      cases where keys are found for host but do not have full validity.
+    - force ssh-keygen to read from stdin to get ssh key fingerprint.
+
+  [ Daniel Kahn Gillmor ]
+
+    - automatically output two copies of the host's public key: one
+    standard ssh public key file, and the other a minimal OpenPGP key with
+    just the latest valid self-sig.
+    - debian/control: corrected alternate dependency from procfile to
+    procmail (which provides /usr/bin/lockfile)
+
+ +[[Download]] it now! -- cgit v1.2.3 From 7e0b85c35531d96ee4e2e06702fc53ae068ad23a Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Sun, 30 Nov 2008 12:18:40 -0500 Subject: gave example on gpg multi-keyring bug. --- .../problems-with-root-owned-gpg-keyrings.mdwn | 97 ++++++++++++++++++++++ 1 file changed, 97 insertions(+) (limited to 'website') diff --git a/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn b/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn index 65268c5..67bc9d2 100644 --- a/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn +++ b/website/bugs/problems-with-root-owned-gpg-keyrings.mdwn @@ -22,3 +22,100 @@ be hiding a bug, rather than getting it fixed correctly. Are there other ways we can deal with this problem? --dkg + +Here is an example when using monkeysphere-server +add-identity-certifier on a host with a newly-installed monkeysphere +installaton. Note that running the same command a second time works +as expected: + + 0 pip:~# monkeysphere-server c+ 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 + gpg: requesting key D21739E9 from hkp server pool.sks-keyservers.net + gpg: key D21739E9: public key "Daniel Kahn Gillmor " imported + gpg: can't create `/var/lib/monkeysphere/gnupg-host/pubring.gpg.tmp': Permission denied + gpg: failed to rebuild keyring cache: file open error + gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model + gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u + gpg: next trustdb check due at 2009-03-30 + gpg: Total number processed: 1 + gpg: imported: 1 (RSA: 1) + Could not receive a key with this ID from the 'pool.sks-keyservers.net' keyserver. + 255 pip:~# monkeysphere-server c+ 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 + gpg: requesting key D21739E9 from hkp server pool.sks-keyservers.net + gpg: key D21739E9: "Daniel Kahn Gillmor " not changed + gpg: Total number processed: 1 + gpg: unchanged: 1 + + key found: + pub 4096R/D21739E9 2007-06-02 [expires: 2012-05-31] + Key fingerprint = 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9 + uid [ unknown] Daniel Kahn Gillmor + uid [ unknown] Daniel Kahn Gillmor + uid [ unknown] Daniel Kahn Gillmor + uid [ unknown] Daniel Kahn Gillmor + uid [ unknown] [jpeg image of size 3515] + sub 2048R/4BFA08E4 2008-06-19 [expires: 2009-06-19] + sub 4096R/21484CFF 2007-06-02 [expires: 2012-05-31] + + Are you sure you want to add the above key as a + certifier of users on this system? (y/N) y + gpg: key D21739E9: public key "Daniel Kahn Gillmor " imported + gpg: Total number processed: 1 + gpg: imported: 1 (RSA: 1) + gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model + gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u + gpg: next trustdb check due at 2009-03-30 + gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc. + This is free software: you are free to change and redistribute it. + There is NO WARRANTY, to the extent permitted by law. + + + pub 4096R/D21739E9 created: 2007-06-02 expires: 2012-05-31 usage: SC + trust: unknown validity: unknown + [ unknown] (1). Daniel Kahn Gillmor + [ unknown] (2) Daniel Kahn Gillmor + [ unknown] (3) Daniel Kahn Gillmor + [ unknown] (4) Daniel Kahn Gillmor + [ unknown] (5) [jpeg image of size 3515] + + + pub 4096R/D21739E9 created: 2007-06-02 expires: 2012-05-31 usage: SC + trust: unknown validity: unknown + Primary key fingerprint: 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9 + + Daniel Kahn Gillmor + Daniel Kahn Gillmor + Daniel Kahn Gillmor + Daniel Kahn Gillmor + [jpeg image of size 3515] + + This key is due to expire on 2012-05-31. + Please decide how far you trust this user to correctly verify other users' keys + (by looking at passports, checking fingerprints from different sources, etc.) + + 1 = I trust marginally + 2 = I trust fully + + + Please enter the depth of this trust signature. + A depth greater than 1 allows the key you are signing to make + trust signatures on your behalf. + + + Please enter a domain to restrict this signature, or enter for none. + + + Are you sure that you want to sign this key with your + key "ssh://pip.fifthhorseman.net" (9B83C17D) + + The signature will be marked as non-exportable. + + + gpg: can't create `/var/lib/monkeysphere/gnupg-host/pubring.gpg.tmp': Permission denied + gpg: failed to rebuild keyring cache: file open error + gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model + gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u + gpg: depth: 1 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 1f, 0u + gpg: next trustdb check due at 2009-03-30 + + Identity certifier added. + 0 pip:~# -- cgit v1.2.3 From 2483b7de82423d6bf0dec774526a2ca9fef3d64d Mon Sep 17 00:00:00 2001 From: Jameson Graef Rollins Date: Sun, 30 Nov 2008 23:27:36 -0500 Subject: add a couple of bugs about posix compliance and the use of getopts instead of getopt. --- src/common | 2 +- src/monkeysphere | 2 +- src/monkeysphere-server | 4 ++-- website/bugs/posix_compliance.mdwn | 9 +++++++++ website/bugs/use_getopts_instead_of_getopt.mdwn | 4 ++++ 5 files changed, 17 insertions(+), 4 deletions(-) create mode 100644 website/bugs/posix_compliance.mdwn create mode 100644 website/bugs/use_getopts_instead_of_getopt.mdwn (limited to 'website') diff --git a/src/common b/src/common index 51b0470..f6000d3 100644 --- a/src/common +++ b/src/common @@ -147,7 +147,7 @@ advance_date() { local shortunits # try things the GNU way first - if date -d "$number $longunits" "$format" >&/dev/null ; then + if date -d "$number $longunits" "$format" >/dev/null 2>&1; then date -d "$number $longunits" "$format" else # otherwise, convert to (a limited version of) BSD date syntax: diff --git a/src/monkeysphere b/src/monkeysphere index 7e800cc..523ddfe 100755 --- a/src/monkeysphere +++ b/src/monkeysphere @@ -158,7 +158,7 @@ EOF log verbose "done." } -function subkey_to_ssh_agent() { +subkey_to_ssh_agent() { # try to add all authentication subkeys to the agent: local sshaddresponse diff --git a/src/monkeysphere-server b/src/monkeysphere-server index a73b253..c4f6985 100755 --- a/src/monkeysphere-server +++ b/src/monkeysphere-server @@ -866,9 +866,9 @@ add_certifier() { # export the key to the host keyring gpg_authentication "--export 0x${fingerprint}!" | gpg_host --import - if [ "$trust" == marginal ]; then + if [ "$trust" = marginal ]; then trustval=1 - elif [ "$trust" == full ]; then + elif [ "$trust" = full ]; then trustval=2 else failure "Trust value requested ('$trust') was unclear (only 'marginal' or 'full' are supported)." diff --git a/website/bugs/posix_compliance.mdwn b/website/bugs/posix_compliance.mdwn new file mode 100644 index 0000000..c2908ad --- /dev/null +++ b/website/bugs/posix_compliance.mdwn @@ -0,0 +1,9 @@ +It would be nice to make all of the Monkeysphere scripts POSIX +compliant, for portability and light-weightedness. Better POSIX +compliance would probably at least be better for compatibility with +o{ther,lder} versions of bash. Unfortunately there are quite a few +bashism at the moment, so this may not be trivial. For instance: + + servo:~/cmrg/monkeysphere/git 0$ checkbashisms -f src/monkeysphere-server 2>&1 | wc -l + 50 + servo:~/cmrg/monkeysphere/git 0$ diff --git a/website/bugs/use_getopts_instead_of_getopt.mdwn b/website/bugs/use_getopts_instead_of_getopt.mdwn new file mode 100644 index 0000000..db087b4 --- /dev/null +++ b/website/bugs/use_getopts_instead_of_getopt.mdwn @@ -0,0 +1,4 @@ +Since Monkeysphere is using bash, it would be nice to use the shell +build in getopts function, instead of the external getopt program. +This would reduce an external dependency, which would definitely be +better for portability. -- cgit v1.2.3