diff options
| -rw-r--r-- | website/bugs/gpg-authentication-cmd_requires_single_input.mdwn (renamed from website/bugs/gpg_authentication_cmd-requires-single-input.mdwn) | 0 | ||||
| -rw-r--r-- | website/why.mdwn | 48 |
2 files changed, 27 insertions, 21 deletions
diff --git a/website/bugs/gpg_authentication_cmd-requires-single-input.mdwn b/website/bugs/gpg-authentication-cmd_requires_single_input.mdwn index d10a164..d10a164 100644 --- a/website/bugs/gpg_authentication_cmd-requires-single-input.mdwn +++ b/website/bugs/gpg-authentication-cmd_requires_single_input.mdwn diff --git a/website/why.mdwn b/website/why.mdwn index 3f6aa7c..272c48c 100644 --- a/website/why.mdwn +++ b/website/why.mdwn @@ -13,43 +13,45 @@ seeing messages like this? Do you actually tediously check the fingerprint against a cryptographically-signed message from the admin, or do you just cross -your fingers and type "yes"? Do you wish there was a better way to do -it? Shouldn't our tools be able to figure this out automatically? +your fingers and type "yes"? Do you wish there was a better way to +verify that the host your connecting to actually is the host you mean +to connect to? Shouldn't our tools be able to figure this out +automatically? Do you use `ssh`'s public key authentication for convenience and/or added security? Have you ever worried about what might happen if you -lose control of your key? (Or did you have a key that was compromised +lost control of your key? (Or did you have a key that was compromised by [the OpenSSL debacle](http://bugs.debian.org/363516)?) How many accounts/machines would you need to clean up to ensure that your old, -bad key is no longer in use? +bad key is no longer in use? Have you ever wished you could phase out an old key and start using a new one without having to comb through every single account you have ever connected to? -## As an `sshd` administrator ## +## As an system administrator ## -If you are a system administrator, have you ever tried to re-key an -SSH server? How did you ease the change along to your users? How did -you keep them from getting the big scary warning messages? +As a system administrator, have you ever tried to re-key an SSH +server? How did you communicate the key change to your users? How +did you keep them from getting the big scary warning message that the +host key had changed? -Have you ever wanted to allow a colleague key-based access to a +Have you ever wanted to allow a remote colleague key-based access to a machine, *without* needing to have a copy of their public key on hand? -Have you ever wanted to be able to revoke the ability of a user's key -to authenticate across the entire infrastructure you manage, without -touching each host by hand? +Have you ever wanted to be able to add or revoke the ability of a +user's key to authenticate across an entire infrastructure you manage, +without touching each host by hand? ## What's the connection? ## -These questions all stem from rough edges we run up against in regular -use of SSH that could be improved by a decent [Public Key +All of these issues are related to a lack of a [Public Key Infrastructure (or -PKI)](http://dictionary.die.net/public%20key%20infrastructure). A PKI -at its core is a mechanism to provide answers to a few basic -questions: +PKI)](http://dictionary.die.net/public%20key%20infrastructure) for +SSH. A PKI at its core is a mechanism to provide answers to a few +basic questions: -* Do we know who a key actually belongs to? How do we know? +* Do we know who (or what host) a key actually belongs to? How do we know? * Is the key still valid for use? Given a clearly stated set of initial assumptions, functional @@ -60,7 +62,7 @@ fingerprints) except in relatively rare situations (e.g. when two people meet in person for the first time). The good news is that this is all possible, and available with free -tools! +tools: welcome to the MonkeySphere! ## Examples ## @@ -76,10 +78,14 @@ administrator. Alice can set up the new `bob` account on `foo.example.org` without needing to give Bob a new passphrase to remember, and without needing to even know Bob's current SSH key. She simply tells `foo` that `Bob -<bob@example.net>` should have access to the `bob` account. +<bob@example.net>` should have access to the `bob` account. The +MonkeySphere on `foo` then verifies Bob's identity through the OpenPGP +Web of Trust and automatically add's Bob's SSH key to the +authorized_keys file for the `bob` account. Bob's first connection to his new `bob` account on `foo.example.org` -is seamless, because all the steps are already in place! Using the +is seamless, because the MonkeySphere on Bob's computer automatically +verifies the host key for `foo.example.org` for Bob. Using the MonkeySphere, Bob never has to "accept" an unintelligible host key or type a password. |