2331
Comment: converted to 1.6 markup
|
4098
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
As described on MultipleCommitters, one way of collaboration (the CVS-like model) is setting up a central [[Repository|repository]] every user pushes his changes to and pulls the others' changes from. This page describes how to create such repositories accessible via a shared ssh account without needing to give full shell access to other people. |
= Shared SSH = {{{#!wiki tip This page describes how to create repositories accessible via a '''single shared SSH account''' without needing to give full shell access to other people. This is just one of many ways to make your repository available to [[MultipleCommitters|multiple committers]], and not necessarily the most common. See PublishingRepositories for a good overview of many ways to allow others to interact with your repository. }}} == hg-ssh == hg-ssh is a python script available in [[http://www.selenic.com/repo/hg-stable/raw-file/tip/contrib/hg-ssh|contrib/hg-ssh]] and was probably installed along with your Mercurial software. Allowed repositories are managed directly in the `authorized_keys` file. Look at the start of the script for usage instructions. When possible use the version that matches your installed version of Mercurial. |
Line 9: | Line 16: |
mercurial-server provides the most complete and easiest-to-use solution to this problem for hosting a collection of repositories on Unix systems. Installing mercurial-server creates a new user, "hg", which will own all the repositories to be shared. Giving access to a new user is as simple as adding their SSH key to a special repository and pushing the changes. mercurial-server can enforce fine-grained permissions and logs all events. | {{{#!wiki note Despite its name, this is not a Mercurial server. It offers an improved management interface for the shared ssh mechanism like that provided by hg-ssh. }}} |
Line 11: | Line 20: |
* [[http://hg.opensource.lshift.net/mercurial-server/file/release_0.6/README]] * [[http://hg.opensource.lshift.net/mercurial-server/file/release_0.6/doc/]] * [[http://hg.opensource.lshift.net/mercurial-server/archive/release_0.6.tar.gz]] |
mercurial-server provides the most complete and easiest-to-use solution to this problem for hosting a collection of repositories on Unix systems. Installing mercurial-server creates a new user, `hg`, which will own all the repositories to be shared. Giving access to a new user is as simple as adding their SSH key to a special repository and pushing the changes. mercurial-server can enforce fine-grained permissions and logs all events. |
Line 15: | Line 22: |
== Other options == | * [[http://www.lshift.net/mercurial-server.html]] |
Line 17: | Line 24: |
There are two alternative systems for achieving the same end, though both require more work to maintain: | mercurial-server is descended from hg-ssh. |
Line 19: | Line 26: |
=== hg-ssh === | == hg-login == |
Line 21: | Line 28: |
A python script available in [[http://www.selenic.com/repo/hg-stable/raw-file/tip/contrib/hg-ssh|contrib/hg-ssh]]. Allowed repositories are managed directly in the authorized_keys file. | HgLogin is a system by MarcSchaefer for creating restricted shared user accounts. |
Line 23: | Line 30: |
Look at the start of the script for usage instructions. | == hg-gateway == |
Line 25: | Line 32: |
mercurial-server is descended from hg-ssh. | "hg-gateway" is inspired by "hg-ssh" and is useful in situations where you wanted to give multiple users hg access via SSH on the same SSH/unix user account. |
Line 27: | Line 34: |
=== hg-login === | Each hg user can be given access some subset of the hg repositories on the server and can even be restricted to have read-only access. "hg-gateway" is useful in situations such as shared web hosting accounts where you do not have root access nor the ability to create additional users. "hg-gateway" also has a command line interface for common administration tasks such as adding new users, granting users permission to repositories etc. Installing hg-gateway is "easy" (edit one script variable and add a line to your authorized_keys) and installation does not require root access. |
Line 29: | Line 36: |
HgLogin is a system by MarcSchaefer for achieving the same end. | Details at [[http://parametricity.net/b/2011/02/20/hg-gateway-supporting-multiple-mercurial-users-on-a-shared-ssh-account/]] |
Line 33: | Line 40: |
When accessing a remote repository via Mercurial's ssh repository type, ''hg'' basically does a |
When accessing a remote repository via Mercurial's `ssh` repository type, `hg` basically does the following: |
Line 40: | Line 46: |
and relies on ssh for authentication and tunneling. When using public key authentication, ssh allows limiting the user to one specific command, which can do all the sanity checks we want and then calls ''hg'' just like ssh would in the example above. Note that every user gets his own private key and his own entry in authorized_keys, which allows the scripts to distinguish between different users and thus enforce e.g. access permissions. |
It relies on `ssh` for authentication and tunneling. When using public key authentication, `ssh` allows limiting the user to one specific command (as described in the [[http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8|sshd manual page]] in the section concerning the `authorized_keys` file format). Such a command, provided by the solutions listed above, can do the necessary sanity checking around the requested operation, and can then call `hg` just like `ssh` would do in the example above. Since every user gets his own private key and his own entry in `authorized_keys`, the solutions presented here are able to distinguish between different users and thus enforce things like access control, even though a single system account (or system user) may be providing the underlying services. Moreover, since a designated command must be executed when those accessing the repository authenticate themselves, it should not be possible for users to start a normal shell and bypass access controls implemented by the designated command (although this does depend on the implementation and proper functioning of the command itself). |
Line 47: | Line 48: |
See also AclExtension, HgWebDirStepByStep. | See also AclExtension, HgWebDirStepByStep, PublishingRepositories, and MultipleCommitters |
Shared SSH
This page describes how to create repositories accessible via a single shared SSH account without needing to give full shell access to other people. This is just one of many ways to make your repository available to multiple committers, and not necessarily the most common. See PublishingRepositories for a good overview of many ways to allow others to interact with your repository.
hg-ssh
hg-ssh is a python script available in contrib/hg-ssh and was probably installed along with your Mercurial software. Allowed repositories are managed directly in the authorized_keys file.
Look at the start of the script for usage instructions. When possible use the version that matches your installed version of Mercurial.
mercurial-server
Despite its name, this is not a Mercurial server. It offers an improved management interface for the shared ssh mechanism like that provided by hg-ssh.
mercurial-server provides the most complete and easiest-to-use solution to this problem for hosting a collection of repositories on Unix systems. Installing mercurial-server creates a new user, hg, which will own all the repositories to be shared. Giving access to a new user is as simple as adding their SSH key to a special repository and pushing the changes. mercurial-server can enforce fine-grained permissions and logs all events.
mercurial-server is descended from hg-ssh.
hg-login
HgLogin is a system by MarcSchaefer for creating restricted shared user accounts.
hg-gateway
"hg-gateway" is inspired by "hg-ssh" and is useful in situations where you wanted to give multiple users hg access via SSH on the same SSH/unix user account.
Each hg user can be given access some subset of the hg repositories on the server and can even be restricted to have read-only access. "hg-gateway" is useful in situations such as shared web hosting accounts where you do not have root access nor the ability to create additional users. "hg-gateway" also has a command line interface for common administration tasks such as adding new users, granting users permission to repositories etc. Installing hg-gateway is "easy" (edit one script variable and add a line to your authorized_keys) and installation does not require root access.
How these work
When accessing a remote repository via Mercurial's ssh repository type, hg basically does the following:
$ ssh hg.example.com hg -R /path/to/repos serve --stdio
It relies on ssh for authentication and tunneling. When using public key authentication, ssh allows limiting the user to one specific command (as described in the sshd manual page in the section concerning the authorized_keys file format). Such a command, provided by the solutions listed above, can do the necessary sanity checking around the requested operation, and can then call hg just like ssh would do in the example above. Since every user gets his own private key and his own entry in authorized_keys, the solutions presented here are able to distinguish between different users and thus enforce things like access control, even though a single system account (or system user) may be providing the underlying services. Moreover, since a designated command must be executed when those accessing the repository authenticate themselves, it should not be possible for users to start a normal shell and bypass access controls implemented by the designated command (although this does depend on the implementation and proper functioning of the command itself).
See also AclExtension, HgWebDirStepByStep, PublishingRepositories, and MultipleCommitters