diff -r ec31ba248edd -r 583ed103e021 README --- a/README Wed Apr 23 09:23:32 2008 +0100 +++ b/README Thu Apr 24 08:27:30 2008 +0100 @@ -20,8 +20,6 @@ developers who have access, and a file "hg-ssh-access.conf" which gives a set of rules defining who can do what to what. -HOW IT WORKS - All of the repositories controlled by these tools are owned by a single user (the "hg" user in what follows), but many remote users can act on them. We don't use file permissions to achieve that - instead, @@ -29,75 +27,23 @@ host using ssh, using ssh URLs of the form "ssh://hg@repository-host/repository-name". A restricted shell prevents them from using this access for unauthorized purposes. - Developers are authenticated only using SSH keys; no other form of -authentication is supported. When a developer attempts to connect to -a repository via ssh, the SSH daemon searches for a match for that -user's key in ~hg/.ssh/authorized_keys. If the developer is -authorised to connect to the repository they will have an entry in -this file. The entry includes a "command" prefix which specifies that -the restricted shell should be used; this shell is passed an argument -identifying the developer. The shell parses the command the developer -is trying to execute, and consults a rules file to see if that -developer is allowed to perform that action on that repository. The -bulk of the work of the restricted shell is done by the Python program -"hg-ssh", but the shell script "hg-ssh-wrapper" sets up some -configuration so that you can change it to suit your local -installation. +authentication is supported. -The file ~hg/.ssh/authorized_keys is generated by "refresh-auth", -which recurses through a directory of files containing SSH keys and -generates an entry in authorized_keys for each one, using the name of -the key file as the identifier for the developer. These keys will -live in the "keys" subdirectory of a repository called "hgadmin". A -hook in this repository re-runs "refresh-auth" on the most recent -version after every push. +QUICK START -Finally, a hook in an extension is run for each changeset that is -remotely committed, which uses the rules file to determine whether to -allow the changeset. - -GETTING STARTED - -This is only one setup - it can be tweaked in many ways, and is as -specific as it is only in the interests of brevity. +You will need -You, and all users of this repository host, will need SSH public key -authentication set up, preferably working with ssh-agent so you don't -have to type in your passphrase all the time. I assume you've done -that in what follows, so if you've done something different you'll -need to change it appropriately. - -Issue these commands to get the repository host started. These are -written out here rather than encapsulated in a script because many of -them may need to be different for your local setup. You will need -root access on the repository host, because you need to create a new -user. +- "sudo" installed +- "sudo" root privileges +- an ssh-key set up with ssh-agent - ssh -A repository-host - ssh-add -L >> /tmp/my-ssh-public-key - sudo adduser --system --shell /bin/sh --group --disabled-password \ - --gecos "Mercurial repositories" hg - sudo -u hg -H -s - cd - mkdir -p admin repos/hgadmin/keys/admin .ssh - cd admin - hg clone http://hg.opensource.lshift.net/hg-admin-tools - cp hg-admin-tools/hg-ssh-wrapper hg-admin-tools/remote-hgrc ~ - cd ../repos/hgadmin - hg init . - echo "init user=admin/*" > hg-ssh-access.conf - cp /tmp/my-ssh-public-key keys/admin/myname - hg add - hg commit -m "initial commit" - cp ~/admin/hg-admin-tools/hgadmin-hgrc .hg/hgrc - ../../admin/hg-admin-tools/refresh-auth ./hg-ssh-wrapper - exit - exit - -You are now the sole user able to change and create repositories on -this repository host. To administer these controls (and test your -access), check out hgadmin: +Ensure there is no user called "hg" on the repository host, and run +"./install" to create them. You are now the sole user able to change +and create repositories on this repository host. To give access to +others, check out hgadmin - as yourself, and on whichever host is most +convenient, but using the ssh-key with which you set up the +repository: mkdir ~/hg cd ~/hg @@ -190,6 +136,33 @@ write user=docs/* file=docs/* read user=docs/* +HOW IT WORKS + +When a developer attempts to connect to a repository via ssh, the SSH +daemon searches for a match for that user's key in +~hg/.ssh/authorized_keys. If the developer is authorised to connect +to the repository they will have an entry in this file. The entry +includes a "command" prefix which specifies that the restricted shell +should be used; this shell is passed an argument identifying the +developer. The shell parses the command the developer is trying to +execute, and consults a rules file to see if that developer is allowed +to perform that action on that repository. The bulk of the work of +the restricted shell is done by the Python program "hg-ssh", but the +shell script "hg-ssh-wrapper" sets up some configuration so that you +can change it to suit your local installation. + +The file ~hg/.ssh/authorized_keys is generated by "refresh-auth", +which recurses through a directory of files containing SSH keys and +generates an entry in authorized_keys for each one, using the name of +the key file as the identifier for the developer. These keys will +live in the "keys" subdirectory of a repository called "hgadmin". A +hook in this repository re-runs "refresh-auth" on the most recent +version after every push. + +Finally, a hook in an extension is run for each changeset that is +remotely committed, which uses the rules file to determine whether to +allow the changeset. + LOCKING YOURSELF OUT If you find yourself "locked out" - that is, that you no longer have