Merge commit 'jrollins/master'
[monkeysphere.git] / website / getting-started-user.mdwn
1 Monkeysphere User README
2 ========================
3
4 You don't have to be an OpenSSH or OpenPGP expert to use the
5 Monkeysphere.  However, you should be comfortable using secure shell
6 (ssh), and you should already have GnuPG installed and an OpenPGP key
7 pair before you begin.
8
9 As a regular user on a system where the monkeysphere package is
10 installed, you probably want to do a few things:
11
12
13 Keep your keyring up-to-date
14 ----------------------------
15
16 Regularly refresh your GnuPG keyring from the keyservers.  This can be
17 done with a simple cronjob.  An example of crontab line to do this is:
18
19         0 12 * * * /usr/bin/gpg --refresh-keys > /dev/null 2>&1
20
21 This would refresh your keychain every day at noon.
22
23
24 Install the monkeysphere software on your system
25 ------------------------------------------------
26
27 If you haven't installed monkeysphere yet, you will need to [download
28 and install](/download) before continuing.
29
30 Make sure that you have the GnuTLS library version 2.6 or later
31 installed on your system. If you can't (or don't want to) upgrade to
32 GnuTLS 2.6 or later, there are patches for GnuTLS 2.4 available in
33 [the Monkeysphere git repo](/community).
34
35
36 Keeping your `known_hosts` file in sync with your keyring
37 ---------------------------------------------------------
38
39 With your keyring updated, you want to make sure that OpenSSH can
40 still see the most recent trusted information about who the various
41 hosts are.  This can be done with the monkeysphere-ssh-proxycommand
42 (see next section) or with the `update-known_hosts` command:
43
44         $ monkeysphere update-known_hosts
45
46 This command will check to see if there is an OpenPGP key for each
47 (non-hashed) host listed in the `known_hosts` file, and then add the
48 key for that host to the `known_hosts` file if one is found.  This
49 command could be added to a crontab as well, if desired.
50
51
52
53 Using `monkeysphere-ssh-proxycommand`(1)
54 ----------------------------------------
55
56 The best way to handle host keys is to use the monkeysphere ssh proxy
57 command.  This command will make sure the `known_hosts` file is
58 up-to-date for the host you are connecting to with ssh.  The best way
59 to integrate this is to add the following line to the "Host *" section
60 of your `~/.ssh/config` file:
61
62         ProxyCommand monkeysphere-ssh-proxycommand %h %p
63
64 The "Host *" section specifies what ssh options to use for all
65 connections. If you don't already have a "Host *" line, you can add it
66 by entering:
67
68         Host *
69
70 On a line by itself. Add the ProxyCommand line just below it.
71
72 Once you've completed this step - you are half-way there. You will now
73 be able to verify servers participating in the monkeysphere provided
74 their keys have been signed by someone that you trust.
75
76 FIXME: We should setup a way for someone to download a test gpg key and
77 then connect to a test server that is signed by this gpg key so users
78 can establish that they are setup correctly.
79
80 The remaining steps will complete the second half: allowing servers to
81 verify you based on your OpenPGP key.
82
83
84 Setting up an OpenPGP authentication key
85 ----------------------------------------
86
87 First things first: you'll need to create an "authentication" subkey
88 for your current key, if you don't already have one.  If you already
89 have a GPG key, you can add an authentication subkey with:
90
91         $ monkeysphere gen-subkey
92
93 If you have more than one secret key, you'll need to specify the key
94 you want to add the subkey to on the command line.
95
96
97
98 Using your OpenPGP authentication key for SSH
99 ---------------------------------------------
100
101 Once you have created an OpenPGP authentication subkey, you will need
102 to feed it to your ssh agent.
103
104 The GnuTLS library supports this operation as of version 2.6, but
105 earlier versions do not.  With a recent version of GnuTLS installed,
106 you can feed your authentication subkey to your ssh agent by running:
107
108         $ monkeysphere subkey-to-ssh-agent
109
110 FIXME: using the key with a single ssh connection?
111
112
113 Establish trust
114 ---------------
115
116 Now that you have the above setup, you will need to establish an
117 acceptable trust path to the admin(s) of a monkeysphere-enabled server
118 that you will be connecting to. You need to do this because the admin
119 is certifying the host, and you need a mechanism to validate that
120 certification. The only way to do that is by indicating who you trust
121 to certify hosts. This is a two step process: first you must sign the
122 key, and then you have to indicate a trust level.
123
124 The process of signing another key is outside the scope of this
125 document, however the [gnupg
126 README](http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/README?root=GnuPG&view=markup)
127 details the signing process and you can find good [documentation
128 ](http://www.debian.org/events/keysigning) online detailing this
129 process.
130
131 If you have signed your admins' key, you need to denote some kind of
132 trust to that key. To do this you should edit the key and use the
133 'trust' command. For the Monkeysphere to trust the assertions that are
134 made about a host, you need full calculated validity to the host
135 certifiers. This can be done either by giving full trust to one
136 host-certifying key, or by giving marginal trust to three different
137 host-certifiers. In the following we demonstrate how to add full trust
138 validity to a host-certifying key:
139         
140         
141         $ gpg --edit-key 'Jane Admin'
142         gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
143         This is free software: you are free to change and redistribute it.
144         There is NO WARRANTY, to the extent permitted by law.
145         
146         
147         pub  4096R/ABCD123A  created: 2007-06-02  expires: 2012-05-31  usage: SC  
148                              trust: unknown       validity: full
149         sub  2048R/01DECAF7  created: 2007-06-02  expires: 2012-05-31  usage: E   
150         [  full  ] (1). Jane Admin <jane_admin@example.net>
151         
152         Command> trust
153         pub  4096R/ABCD123A  created: 2007-06-02  expires: 2012-05-31  usage: SC  
154                              trust: unknown       validity: full
155         sub  2048R/01DECAF7  created: 2007-06-02  expires: 2012-05-31  usage: E   
156         [  full  ] (1). Jane Admin <jane_admin@example.net>
157         
158         Please decide how far you trust this user to correctly verify other users' keys
159         (by looking at passports, checking fingerprints from different sources, etc.)
160         
161           1 = I don't know or won't say
162           2 = I do NOT trust
163           3 = I trust marginally
164           4 = I trust fully
165           5 = I trust ultimately
166           m = back to the main menu
167         
168         Your decision? 4
169         
170         pub  4096R/ABCD123A  created: 2007-06-02  expires: 2012-05-31  usage: SC  
171                              trust: full          validity: full
172         sub  2048R/01DECAF7  created: 2007-06-02  expires: 2012-05-31  usage: E   
173         [  full  ] (1). Jane Admin <jane_admin@example.net>
174         Please note that the shown key validity is not necessarily correct
175         unless you restart the program.
176         
177         Command> save
178         Key not changed so no update needed.
179         $ 
180
181 Note: Due to a limitation with gnupg, it is not currently possible to
182 limit the domain scope properly, which means that if you fully trust
183 an admin, you'll trust all their certifications.
184
185 Because the Monkeysphre relies on GPG's definition of the OpenPGP web
186 of trust, it is important to understand [how GPG calculates User ID
187 validity for a key](/trust-models).
188
189
190 Miscellaneous
191 -------------
192
193 Users can also maintain their own `~/.ssh/authorized_keys` files with
194 the Monkeysphere.  This is primarily useful for accounts on hosts that
195 are not already systematically using the Monkeysphere for user
196 authentication.  If you're not sure whether this is the case for your
197 host, ask your system administrator.
198
199 If you want to do this as a regular user, use the
200 `update-authorized_keys` command:
201
202         $ monkeysphere update-authorized_keys
203
204 This command will take all the user IDs listed in the
205 `~/.monkeysphere/authorized_user_ids` file and check to see if
206 there are acceptable keys for those user IDs available.  If so, they
207 will be added to the `~/.ssh/authorized_keys` file.
208
209 You must have indicated reasonable ownertrust in some key for this
210 account, or no keys will be found with trusted certification paths.
211
212 If you find this useful, you might want to place this command in your
213 crontab so that revocations and rekeyings can take place
214 automatically.