diff options
Diffstat (limited to 'website')
| -rw-r--r-- | website/bugs/add-man-pages-to-website.mdwn | 12 | ||||
| -rw-r--r-- | website/bugs/handle-passphrase-locked-secret-keys.mdwn | 6 | ||||
| -rw-r--r-- | website/bugs/install-seckey2sshagent-in-usr-bin.mdwn | 16 | ||||
| -rw-r--r-- | website/bugs/list-id-certifiers-should-run-non-priv.mdwn | 19 | ||||
| -rw-r--r-- | website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn | 7 | ||||
| -rw-r--r-- | website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn | 4 | ||||
| -rw-r--r-- | website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn | 12 | ||||
| -rw-r--r-- | website/bugs/multiple-hostnames.mdwn | 2 | ||||
| -rw-r--r-- | website/bugs/revoke-hostname-revoking-wrong-userid.mdwn | 94 | ||||
| -rw-r--r-- | website/download.mdwn | 2 | ||||
| -rw-r--r-- | website/index.mdwn | 13 | ||||
| -rw-r--r-- | website/news/release-0.8-1.mdwn | 5 | ||||
| -rw-r--r-- | website/news/release-0.9-1.mdwn | 8 | ||||
| -rw-r--r-- | website/why.mdwn | 126 |
14 files changed, 317 insertions, 9 deletions
diff --git a/website/bugs/add-man-pages-to-website.mdwn b/website/bugs/add-man-pages-to-website.mdwn new file mode 100644 index 0000000..4a8d2e2 --- /dev/null +++ b/website/bugs/add-man-pages-to-website.mdwn @@ -0,0 +1,12 @@ +[[meta title="Add man pages to web site"]] + +We should publish the various monkeysphere man pages in browsable form +somewhere under http://monkeysphere.info/. Ideally, this would be +updated automatically from the sources for the official man pages +themselves. + +This strikes me as an ikiwiki subproject (implementing a man2html wiki +compilation language perhaps?). + +Interestingly, [ikiwiki's own man page](http://ikiwiki.info/usage/) +appears to be written in markdown and then converted to nroff. diff --git a/website/bugs/handle-passphrase-locked-secret-keys.mdwn b/website/bugs/handle-passphrase-locked-secret-keys.mdwn index b66e4c7..ae5bf72 100644 --- a/website/bugs/handle-passphrase-locked-secret-keys.mdwn +++ b/website/bugs/handle-passphrase-locked-secret-keys.mdwn @@ -36,8 +36,10 @@ work for reasonable values of `$KEYID`: mkfifo "$TMPDIR/passphrase" kname="MonkeySphere Key $KEYID" mkfifo "$TMPDIR/$kname" - ssh-agent "Please enter the passphrase for MonkeySphere key $KEYID" >"$TMPDIR/passphrase" & - gpg --passphrase-fd 3 3<"$TMPDIR/passphrase" --export-options export-reset-subkey-passwd,export-minimal,no-export-attributes --export-secret-subkeys "$KEYID"\! | openpgp2ssh "$KEYID" > "$TMPDIR/$kname" + ssh-askpass "Please enter the passphrase for MonkeySphere key $KEYID" >"$TMPDIR/passphrase" & + gpg --passphrase-fd 3 3<"$TMPDIR/passphrase" \ + --export-options export-reset-subkey-passwd,export-minimal,no-export-attributes \ + --export-secret-subkeys "$KEYID"\! | openpgp2ssh "$KEYID" > "$TMPDIR/$kname" & (cd "$TMPDIR" && ssh-add -c "$kname") rm -rf "$TMPDIR" diff --git a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn b/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn index 5b19b13..0163727 100644 --- a/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn +++ b/website/bugs/install-seckey2sshagent-in-usr-bin.mdwn @@ -25,3 +25,19 @@ part about verifying you to a server. Then it could say: if you're really interested, you can run this hacky script but we make no guarantees. -- Sir Jam Jam + +--- + +I just realized that i think i can test for the presence of [GNU-dummy +support in +GnuTLS](http://lists.gnu.org/archive/html/gnutls-devel/2008-08/msg00005.html), +which means that we can cleanly test whether the proposed [handling of +passphrase-locked secret +keys](bugs/handle-passphrase-locked-secret-keys/) is functional. With +that in mind, I'd like to propose that we could resolve this bug +simply by adding a new subcommand: `monkeysphere authkey-to-agent`, +which would fail in the absence of a functionally-patched GnuTLS. + +Would this proposal be sufficient to resolve this bug? + +--dkg diff --git a/website/bugs/list-id-certifiers-should-run-non-priv.mdwn b/website/bugs/list-id-certifiers-should-run-non-priv.mdwn new file mode 100644 index 0000000..2a3d533 --- /dev/null +++ b/website/bugs/list-id-certifiers-should-run-non-priv.mdwn @@ -0,0 +1,19 @@ +[[meta title="list-identity-certfiers should run as the non-privileged user"]] + +Right now, `monkeysphere-server list-identity-certifiers` runs as the +superuser, and just lists the keys in the host's keyring. This might +not be the actual list of valid id certifiers, for a number of reasons: + +* the keys themselves might have been revoked by the owner + +* the id-certifiers might have been added with a different trust + level, or a regexp/domain limitation. + +It would make more sense to derive the list of trusted certifiers +directly from the keyrings as seen by the non-privileged +`monkeysphere` user, since this user's keyrings are what are going to +judge the validity of various user IDs. + +--- + +[[bugs/done]] 2008-08-16 in a29b35e69d0fab5f2de42ed5edd9512a6552e75a diff --git a/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn b/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn index 51cf57e..e97b49c 100644 --- a/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn +++ b/website/bugs/monkeysphere-gen-subkey-fails-without-agent.mdwn @@ -135,3 +135,10 @@ it. Alternately, we could use `--passwd-fd` and `ssh-agent`, along the lines i proposed [for handling passphrase-locked secret keys](/bugs/handle-passphrase-locked-secret-keys). + +--- + +[[bugs/done]] as of 2008-08-15 16:48:26-0400 (to be released in 0.8-1) + +I opted to go with the `ssh-askpass` route, and fall back to echoing +stuff to a fifo directly if `ssh-askpass` is not available. diff --git a/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn b/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn index 3fbf19f..85f79f1 100644 --- a/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn +++ b/website/bugs/monkeysphere-should-respect-keyserver-settings-in-gpg.mdwn @@ -16,3 +16,7 @@ following order instead: * default value of subkeys.pgp.net -- Sir Jam Jam + +--- + +[[bugs/done]] 2008-08-15 in ab5cfab5be64cfb5e01c2b660587da43b3097cad diff --git a/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn b/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn index 965f198..028c8f9 100644 --- a/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn +++ b/website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn @@ -20,3 +20,15 @@ at least, would be for silent output to be the default and have a -v/--verbose option to get the output. Or - maybe these should be environmental variables? In any event - someway to suppress informational output would be a useful improvement. + +------ + +I'd be fine with silent mode as a default, with a more verbose mode +accessible to the user who desires it. + +I'd prefer an environment variable (e.g. `MONKEYSPHERE_VERBOSE` or +`MONKEYSPHERE_DEBUG`) over a command-line (e.g. `--verbose`) option, +personally. It's more in keeping with the model we've used in general +so far. + +--dkg diff --git a/website/bugs/multiple-hostnames.mdwn b/website/bugs/multiple-hostnames.mdwn index 7597af5..f4920fd 100644 --- a/website/bugs/multiple-hostnames.mdwn +++ b/website/bugs/multiple-hostnames.mdwn @@ -35,3 +35,5 @@ probably prompt the administrator to re-publish the host key as well, to ensure that the new User IDs are published. --dkg + +[[bugs/done]] on 2008-08-15 15:00:02-0400 in 84b775ff0b36ec4b86e6708844ad2d678eced403 diff --git a/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn b/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn new file mode 100644 index 0000000..f785a9d --- /dev/null +++ b/website/bugs/revoke-hostname-revoking-wrong-userid.mdwn @@ -0,0 +1,94 @@ +[[meta title="revoke-hostname function revokes wrong hostname user ID"]] + +It appears that the monkeysphere-server revoke-hostname function will +occasionaly revoke the wrong hostname. I say occasionally, but it +seems to be doing it pretty consistently for me at the moment: + + servo:~ 0$ sudo monkeysphere-server n- servo.finestructure.net + The following host key user ID will be revoked: + ssh://servo.finestructure.net + Are you sure you would like to revoke this user ID? (y/N) y + 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. + + Secret key is available. + + pub 1024R/9EEAC276 created: 2008-07-10 expires: never usage: CA + trust: ultimate validity: ultimate + [ultimate] (1) ssh://localhost.localdomain + [ultimate] (2). ssh://servo.finestructure.net + [ revoked] (3) ssh://jamie.rollins + [ revoked] (4) asdfsdflkjsdf + [ revoked] (5) ssh://asdfsdlf.safsdf + [ revoked] (6) ssh://bar.baz + [ revoked] (7) ssh://foo.bar + [ revoked] (8) ssh:// + + + pub 1024R/9EEAC276 created: 2008-07-10 expires: never usage: CA + trust: ultimate validity: ultimate + [ultimate] (1)* ssh://localhost.localdomain + [ultimate] (2). ssh://servo.finestructure.net + [ revoked] (3) ssh://jamie.rollins + [ revoked] (4) asdfsdflkjsdf + [ revoked] (5) ssh://asdfsdlf.safsdf + [ revoked] (6) ssh://bar.baz + [ revoked] (7) ssh://foo.bar + [ revoked] (8) ssh:// + + Please select the reason for the revocation: + 0 = No reason specified + 4 = User ID is no longer valid + Q = Cancel + (Probably you want to select 4 here) + Enter an optional description; end it with an empty line: + Reason for revocation: User ID is no longer valid + Hostname removed by monkeysphere-server 2008-08-16T17:34:02 + + pub 1024R/9EEAC276 created: 2008-07-10 expires: never usage: CA + trust: ultimate validity: ultimate + [ revoked] (1) ssh://localhost.localdomain + [ultimate] (2). ssh://servo.finestructure.net + [ revoked] (3) ssh://jamie.rollins + [ revoked] (4) asdfsdflkjsdf + [ revoked] (5) ssh://asdfsdlf.safsdf + [ revoked] (6) ssh://bar.baz + [ revoked] (7) ssh://foo.bar + [ revoked] (8) ssh:// + + gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model + gpg: depth: 0 valid: 1 signed: 2 trust: 0-, 0q, 0n, 0m, 0f, 1u + gpg: depth: 1 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 2f, 0u + gpg: next trustdb check due at 2012-01-07 + sec 1024R/9EEAC276 2008-07-10 + Key fingerprint = C094 43E0 6882 8BE2 E9AD 516C 45CF 974D 9EEA C276 + uid ssh://servo.finestructure.net + uid [ revoked] ssh://localhost.localdomain + uid [ revoked] ssh://jamie.rollins + uid [ revoked] asdfsdflkjsdf + uid [ revoked] ssh://asdfsdlf.safsdf + uid [ revoked] ssh://bar.baz + uid [ revoked] ssh://foo.bar + uid [ revoked] ssh:// + + NOTE: User ID revoked, but revokation not published. + Run 'monkeysphere-server publish-key' to publish the revocation. + servo:~ 0$ + +Clearly this is unacceptable. gpg does not let you can't specify a +uid to revoke from the command line. The uid revokation can only be +done through edit-key. We do edit-key scripting in other contexts, +but to revoke a user id you have to specify the uid by "number". We +currently try to guess the number from the ordering of the output of +list-key. However, this output does not appear to coincide with the +ordering in edit-key. I don't have a good solution or fix at the +moment. Suggestions are most welcome. It may just require some trial +and error with edit-key to come up with something workable. + +This underlines the problem that gpg is currently not very well suited +for manipulating gpg keyrings non-interactively. It's possible that I +just haven't figured out how to do it yet, but it's not very clear if +it is possible. It would be nice to have some alternate tools to use. + +-- Big Jimmy. diff --git a/website/download.mdwn b/website/download.mdwn index 5bd2f2a..dbae309 100644 --- a/website/download.mdwn +++ b/website/download.mdwn @@ -28,7 +28,7 @@ The git repo from this web site: [Jameson Graef Rollins](http://cmrg.fifthhorseman.net/wiki/jrollins): - git clone http://lair.fifthhorseman.net/~jrollins/git/monkeysphere.git monkeysphere + git clone git://lair.fifthhorseman.net/~jrollins/monkeysphere monkeysphere [Daniel Kahn Gillmor](http://cmrg.fifthhorseman.net/wiki/dkg): diff --git a/website/index.mdwn b/website/index.mdwn index 853c75b..6583e18 100644 --- a/website/index.mdwn +++ b/website/index.mdwn @@ -9,7 +9,7 @@ yourself and the servers you administer or connect to. OpenPGP keys are tracked via GnuPG, and managed in the `known_hosts` and `authorized_keys` files used by OpenSSH for connection authentication. -[[bugs]] | [[download]] | [[news]] | [[documentation|doc]] +[why?](/why) | [[bugs]] | [[download]] | [[news]] | [[documentation|doc]] ## Conceptual overview ## @@ -26,13 +26,14 @@ keys for authenticating to a server (known as "`PubkeyAuthentication`"), rather than relying on a password exchange. But again, the public part of the key needs to be transmitted to the server through a secure out-of-band channel (usually via a separate -password-based SSH connection) in order for this type of -authentication to work +password-based SSH connection or a (hopefully signed) e-mail to the +system administrator) in order for this type of authentication to +work. [OpenSSH](http://openssh.com/) currently provides a functional way to -managing the RSA and DSA keys required for these interactions through -the `known_hosts` and `authorized_keys` files. However, it lacks -any type of [Public Key Infrastructure +manage the RSA and DSA keys required for these interactions through +the `known_hosts` and `authorized_keys` files. However, it lacks any +type of [Public Key Infrastructure (PKI)](http://en.wikipedia.org/wiki/Public_Key_Infrastructure) that can verify that the keys being used really are the one required or expected. diff --git a/website/news/release-0.8-1.mdwn b/website/news/release-0.8-1.mdwn new file mode 100644 index 0000000..ed4ed7d --- /dev/null +++ b/website/news/release-0.8-1.mdwn @@ -0,0 +1,5 @@ +[[meta title="MonkeySphere 0.8-1 released!"]] + +MonkeySphere 0.8-1 has been released. This release contains bugfixes, +some UI re-arrangement, and new features for `monkeysphere-server`, +among other things. [[download]] it now! diff --git a/website/news/release-0.9-1.mdwn b/website/news/release-0.9-1.mdwn new file mode 100644 index 0000000..8a51f42 --- /dev/null +++ b/website/news/release-0.9-1.mdwn @@ -0,0 +1,8 @@ +[[meta title="MonkeySphere 0.9-1 released!"]] + +# MonkeySphere 0.9-1 released! # + +MonkeySphere 0.9-1 has been released. This release contains a serious +bugfix related to host key expiration, and provides the ability for +server administrators to extend the lifetime of their keys. +[[download]] it now! diff --git a/website/why.mdwn b/website/why.mdwn new file mode 100644 index 0000000..3f6aa7c --- /dev/null +++ b/website/why.mdwn @@ -0,0 +1,126 @@ +[[meta title="Why should you be interested in the MonkeySphere?"]] + +# Why should you be interested in the MonkeySphere? # + +## As an `ssh` user ## + +Do you use `ssh` to connect to remote machines? Are you tired of +seeing messages like this? + + The authenticity of host 'foo.example.org (192.0.2.3)' can't be established. + RSA key fingerprint is 17:f4:2b:22:90:d4:98:9a:a2:c5:95:4e:4a:89:be:90. + Are you sure you want to continue connecting (yes/no)? + +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? + +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 +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? + +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 ## + +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? + +Have you ever wanted to allow a 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? + +## 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 +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: + +* Do we know who 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 +cryptographic tools, and a PKI, these questions can be clearly +answered in an automated fashion. We should not need to ask humans to +do complicated, error-prone things (e.g. checking host key +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! + +## Examples ## + +Bob is an `ssh` user, and has just been given an account on +`foo.example.org` by Alice, the `example.org` system administrator, +who he knows. + +Bob already trusts Alice to properly identify all `example.org` +servers. Alice already knows who Bob is, and the new machine `foo` +knows that it can rely on Alice's certifications because Alice is its +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's first connection to his new `bob` account on `foo.example.org` +is seamless, because all the steps are already in place! Using the +MonkeySphere, Bob never has to "accept" an unintelligible host key or +type a password. + +When Bob decides to change the key he uses for SSH authentication, he +can do so at once: he generates a new key, revokes his old key, and +publishes these changes to the public keyservers. The next time he's +ready to log into `foo.example.org`, it accepts his new key -- and it +*won't* accept his old key any longer. + +The same thing works for Alice when she decides to re-key +`foo.example.org` (let's say Alice learned that Eve has compromised +the old key). Alice generates a new key, revokes the old one, +publishes the changes, and the next time Bob connects, he connects as +smoothly as ever. And if Eve tries to use the old host key to +masquerade as `foo`, Bob's SSH client will refuse to let him connect! + +Alice can even quit as `example.org` system administrator, and revoke +her certifications of all `example.org` hosts. As long as Bob knows +and trusts the new `example.org` system administrator to identify +hosts in that domain, there's no problem. + +## Why OpenPGP? ## + +We believe that OpenPGP is the right PKI to use for this project. It +allows a very flexible trust model, ranging all over the map, at the +choice of the user: + +* individual per-host certifications by each client (much like the + stock OpenSSH behavior), + +* strict centralized Certificate Authorities (much like proposed X.509 + models), and + +* a more human-centric model that recognizes individual differences in + ranges of trust and acceptance. + +Even if Bob *doesn't* trust Alice to identify *all* `example.org` +hosts, his first connection to `foo.example.org` should give him more +than an unintelligible string to accept or reject. It should also +give him the information that Alice (and perhaps her colleague +Charles) have certified the key. This is far more useful information +than the current infrastructure allows, and is more meaningful to +actual humans using these tools than some message like "Certified by +GloboTrust". |