website/advanced-user.mdwn

   1 [[!meta title="Advanced usage of the Monkeysphere"]]
   2
   3 Advanced usage of the monkeysphere
   4 ==================================
   5
   6
   7 Keeping your `known_hosts` file in sync with your keyring
   8 ---------------------------------------------------------
   9
  10 If you want to keep your keyring updated without attempting
  11 connections to a remote host, you want to make sure that OpenSSH can
  12 still see the most recent trusted information about who the various
  13 hosts are.  You might also want to check on hosts that were not
  14 originally in the Monkeysphere, to see if their host key is now
  15 published.
  16
  17 You can do this kind of independent update with the
  18 `update-known_hosts` command:
  19
  20         $ monkeysphere update-known_hosts
  21
  22 This command will check to see if there is an OpenPGP key for each
  23 (non-hashed) host listed in the `known_hosts` file, and then add the
  24 key for that host to the `known_hosts` file if one is found.  This
  25 command could be added to a crontab, if desired.
  26
  27
  28
  29 Establishing trust
  30 ------------------
  31
  32 The Monkeysphere is predicated on the idea that users and
  33 administrators know each other (or know people who know each other,
  34 etc).  It uses the Web of Trust to explicitly represent those links.
  35 If you haven't used the Web of Trust explicitly, you will need to
  36 establish an acceptable trust path to the admin(s) of the
  37 monkeysphere-enabled servers that you will be connecting to. You need
  38 to do this because the admin is certifying the host, and you need a
  39 mechanism to validate that certification. The only way to do that is
  40 by indicating who you trust to certify hosts. This is a two step
  41 process: first you must sign the key, and then you have to indicate a
  42 trust level.  If you do not indicate that you trust the administrator
  43 to certify host keys, then the monkeysphere will show you her
  44 certification on every connection, but will not treat it as an
  45 automatic verification.
  46
  47 The process of signing another key is outside the scope of this
  48 document, however the [gnupg
  49 README](http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/README?root=GnuPG&view=markup)
  50 details the signing process and you can find good [documentation
  51 ](http://www.debian.org/events/keysigning) online detailing this
  52 process.
  53
  54 If you have signed your admins' key, you need to denote some kind of
  55 trust to that key. To do this you should edit the key and use the
  56 'trust' command. For the Monkeysphere to trust the assertions that are
  57 made about a host, you need full calculated validity to the host
  58 certifiers. This can be done either by giving full trust to one
  59 host-certifying key, or by giving marginal trust to three different
  60 host-certifiers. In the following we demonstrate how to add full trust
  61 validity to a host-certifying key:
  62
  63
  64         $ gpg --edit-key 'Jane Admin'
  65         gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
  66         This is free software: you are free to change and redistribute it.
  67         There is NO WARRANTY, to the extent permitted by law.
  68
  69
  70         pub  4096R/ABCD123A  created: 2007-06-02  expires: 2012-05-31  usage: SC
  71                              trust: unknown       validity: full
  72         sub  2048R/01DECAF7  created: 2007-06-02  expires: 2012-05-31  usage: E
  73         [  full  ] (1). Jane Admin <jane_admin@example.net>
  74
  75         Command> trust
  76         pub  4096R/ABCD123A  created: 2007-06-02  expires: 2012-05-31  usage: SC
  77                              trust: unknown       validity: full
  78         sub  2048R/01DECAF7  created: 2007-06-02  expires: 2012-05-31  usage: E
  79         [  full  ] (1). Jane Admin <jane_admin@example.net>
  80
  81         Please decide how far you trust this user to correctly verify other users' keys
  82         (by looking at passports, checking fingerprints from different sources, etc.)
  83
  84           1 = I don't know or won't say
  85           2 = I do NOT trust
  86           3 = I trust marginally
  87           4 = I trust fully
  88           5 = I trust ultimately
  89           m = back to the main menu
  90
  91         Your decision? 4
  92
  93         pub  4096R/ABCD123A  created: 2007-06-02  expires: 2012-05-31  usage: SC
  94                              trust: full          validity: full
  95         sub  2048R/01DECAF7  created: 2007-06-02  expires: 2012-05-31  usage: E
  96         [  full  ] (1). Jane Admin <jane_admin@example.net>
  97         Please note that the shown key validity is not necessarily correct
  98         unless you restart the program.
  99
 100         Command> save
 101         Key not changed so no update needed.
 102         $
 103
 104 Note: Due to a limitation with gnupg, it is not currently possible to
 105 limit the domain scope properly, which means that if you fully trust
 106 an admin, you'll trust all their certifications.
 107
 108 Because the Monkeysphere currently relies on GPG's definition of the
 109 OpenPGP web of trust, it is important to understand [how GPG
 110 calculates User ID validity for a key](/trust-models).
 111
 112
 113 Miscellaneous
 114 -------------
 115
 116 Users can also maintain their own `~/.ssh/authorized_keys` files with
 117 the Monkeysphere directly.  This is primarily useful for accounts on
 118 hosts that are not already systematically using the Monkeysphere for
 119 user authentication.  If you're not sure whether this is the case for
 120 your host, ask your system administrator.
 121
 122 If you want to do this as a regular user, use the
 123 `update-authorized_keys` command:
 124
 125         $ monkeysphere update-authorized_keys
 126
 127 This command will take all the user IDs listed in the
 128 `~/.monkeysphere/authorized_user_ids` file and check to see if
 129 there are acceptable keys for those user IDs available.  If so, they
 130 will be added to the `~/.ssh/authorized_keys` file.
 131
 132 You must have indicated reasonable ownertrust in some key for this
 133 account, or no keys will be found with trusted certification paths.
 134
 135 If you find this useful, you might want to place this command in your
 136 crontab so that revocations and rekeyings can take place
 137 automatically.