21 are authenticated only using SSH keys; no other form of authentication is |
21 are authenticated only using SSH keys; no other form of authentication is |
22 supported. |
22 supported. |
23 |
23 |
24 To give a user access to the repository, place their key in an |
24 To give a user access to the repository, place their key in an |
25 appropriately-named subdirectory of "/etc/mercurial-server/keys" and run |
25 appropriately-named subdirectory of "/etc/mercurial-server/keys" and run |
26 "/etc/mercurial-server/refresh-auth". You can then control what access they |
26 "/usr/local/lib/mercurial-server/refresh-auth". You can then control what |
27 have to what repositories by editing the control file |
27 access they have to what repositories by editing the control file |
28 "/etc/mercurial-server/access.conf", which can match the names of these |
28 "/etc/mercurial-server/access.conf", which can match the names of these keys |
29 keys against a glob pattern. |
29 against a glob pattern. |
30 |
30 |
31 For convenient remote control of access, you can instead (if you have the |
31 For convenient remote control of access, you can instead (if you have the |
32 privileges) make changes to a special repository called "hgadmin", which |
32 privileges) make changes to a special repository called "hgadmin", which |
33 contains its own "access.conf" file and "keys" directory. Changes pushed to |
33 contains its own "access.conf" file and "keys" directory. Changes pushed to |
34 this repository take effect immediately. The two "access.conf" files are |
34 this repository take effect immediately. The two "access.conf" files are |
56 Place your SSH public key in the directory "/etc/mercurial-server/keys/root". |
56 Place your SSH public key in the directory "/etc/mercurial-server/keys/root". |
57 I suggest creating yourself a directory and naming the key after your hostname |
57 I suggest creating yourself a directory and naming the key after your hostname |
58 (ie the file is called something like |
58 (ie the file is called something like |
59 "/etc/mercurial-server/keys/root/yourname/yourhostname") so that you can |
59 "/etc/mercurial-server/keys/root/yourname/yourhostname") so that you can |
60 easily manage users who have a different key on each host they use. Then run |
60 easily manage users who have a different key on each host they use. Then run |
61 "/etc/mercurial-server/refresh-auth". |
61 "/usr/local/lib/mercurial-server/refresh-auth". |
62 |
62 |
63 The repository is now ready to use, and you are now the sole user able to |
63 The repository is now ready to use, and you are now the sole user able to |
64 change and create repositories on this repository host. |
64 change and create repositories on this repository host. |
65 |
65 |
66 CREATING REPOSITORIES |
66 CREATING REPOSITORIES |
79 mercurial-server). You can add other root users by putting their keys next to |
79 mercurial-server). You can add other root users by putting their keys next to |
80 yours, or you can make less privileged users by putting their keys in the |
80 yours, or you can make less privileged users by putting their keys in the |
81 "keys/users" subdirectory - these users will be able to read and write to any |
81 "keys/users" subdirectory - these users will be able to read and write to any |
82 repository (except one - see below) but will not be able to create new |
82 repository (except one - see below) but will not be able to create new |
83 repositories. As always, when you change "/etc/mercurial-server/keys" you need |
83 repositories. As always, when you change "/etc/mercurial-server/keys" you need |
84 to re-run "/etc/mercurial-server/refresh-auth". |
84 to re-run "/usr/local/lib/mercurial-server/refresh-auth". |
85 |
85 |
86 LOGGING |
86 LOGGING |
87 |
87 |
88 Every push and pull is logged with the key used: see the file .hg/serve-log in |
88 Every push and pull is logged with the key used: see the file .hg/serve-log in |
89 each repository. |
89 each repository. |
211 |
211 |
212 When a developer attempts to connect to a repository via ssh, the SSH daemon |
212 When a developer attempts to connect to a repository via ssh, the SSH daemon |
213 searches for a match for that user's key in ~hg/.ssh/authorized_keys. If the |
213 searches for a match for that user's key in ~hg/.ssh/authorized_keys. If the |
214 developer is authorised to connect to the repository they will have an entry |
214 developer is authorised to connect to the repository they will have an entry |
215 in this file. The entry includes a "command" prefix which specifies that the |
215 in this file. The entry includes a "command" prefix which specifies that the |
216 restricted shell should be used; this shell is passed an argument identifying |
216 restricted shell "/usr/local/lib/mercurial-server/hg-ssh" should be used; this |
217 the developer. The shell parses the command the developer is trying to |
217 shell is passed an argument identifying the developer. The shell parses the |
218 execute, and consults a rules file to see if that developer is allowed to |
218 command the developer is trying to execute, and consults a rules file to see |
219 perform that action on that repository. The bulk of the work of the restricted |
219 if that developer is allowed to perform that action on that repository. |
220 shell is done by the Python program "hg-ssh", but the shell script |
|
221 "hg-ssh-wrapper" sets up some configuration so that you can change it to suit |
|
222 your local installation. |
|
223 |
220 |
224 The file ~hg/.ssh/authorized_keys is generated by "refresh-auth", which |
221 The file ~hg/.ssh/authorized_keys is generated by "refresh-auth", which |
225 recurses through two directories of files containing SSH keys and generates an |
222 recurses through two directories of files containing SSH keys and generates an |
226 entry in authorized_keys for each one, using the name of the key file as the |
223 entry in authorized_keys for each one, using the name of the key file as the |
227 identifier for the developer. These keys will live in the "keys" subdirectory |
224 identifier for the developer. These keys will live in the "keys" subdirectory |