README
changeset 81 f23736ad66bc
parent 66 2f0ea1163b9e
child 82 7369ff737684
equal deleted inserted replaced
80:fcb20d7593e6 81:f23736ad66bc
    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