summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJameson Graef Rollins <jrollins@phys.columbia.edu>2008-08-20 16:21:33 -0700
committerJameson Graef Rollins <jrollins@phys.columbia.edu>2008-08-20 16:21:33 -0700
commit4c40d9a2f75e5c563979cae5b3e4e7bce23e3dff (patch)
tree85e88fe9b66f082ca96d71b5ede38beffc798645
parent81b95ea5c16e589d89d082f9572ab8a8bd5fc54f (diff)
some web site updates
-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.mdwn48
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.