Differences between revisions 47 and 65 (spanning 18 versions)
Revision 47 as of 2011-03-01 13:19:40
Size: 4100
Editor: RoshanJames
Comment:
Revision 65 as of 2020-05-03 08:02:54
Size: 6583
Editor: timeless
Comment: minor grammatical cleanup
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Line 6: Line 5:
== hg-ssh ==
hg-ssh is a python script available in [[https://www.mercurial-scm.org/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.
Line 7: Line 8:
Look at the [[https://www.mercurial-scm.org/repo/hg-stable/file/tip/contrib/hg-ssh#l12|start of the script]] for usage instructions. When possible use the version that matches your installed version of Mercurial.
Line 8: Line 10:
== 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.
A step-by-step guide for adding an `hg` user and configuring hg-ssh can be found [[https://sites.google.com/site/ucdcsssg/announcements/howtocollaborateusingmercurialwithhg-ssh|here]]. See [[SecuringRepositories]] for guidance on how to '''secure''' a Mercurial repository published via SSH.
Line 15: Line 13:
Line 17: Line 14:
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.  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 19: Line 16:
Line 22: Line 18:
 * [[http://www.lshift.net/mercurial-server.html]]  * http://www.lshift.net/mercurial-server.html
Line 26: Line 22:
Root privileges are required to install it.
Line 27: Line 25:
Line 31: Line 28:
"hg-gateway" is inspired by "hg-ssh" and is useful in shared hosting like situations where you wanted to give multiple users hg access via SSH on the same SSH/unix user account.
Line 32: Line 30:
"hg-gateway" is inspired by "hg-ssh" and is useful for situations where you wanted to support multiple hg users via SSH on the same SSH user account. "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. 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" 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 does not require root access.
Line 34: Line 32:
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" (put the script in your PATH and edit just one variable in the common case) and installation does not require root access. Details at http://parametricity.net/b/hg-gateway
Line 36: Line 34:
Details at [[http://parametricity.net/b/2011/02/20/hg-gateway-supporting-multiple-mercurial-users-on-a-shared-ssh-account/]] == hgadmin ==
hgadmin also contains a wrapper for ssh (like "hg-ssh").

Unlike hg-ssh, this wrapper will examine the web-permissions in the managed repository to determine whether access is allowed.

hgadmin also includes a script to automatically generate the web-permissions, to manage http passwords (contained in an `htpasswd` file), and to manage ssh keys.

Its configuration supports users and groups and has a syntax similar to the standard svn access configuration.

hgadmin can be found at https://bitbucket.org/JakobKrainz/hgadmin

== hgssh2 ==
'''With recent versions of mercurial, this script fails to allow read-only users to pull from a repository'''

A python script to control ssh access to mercurial repositories, modified from hg-ssh.

It allows you to specify a simple config file to control the access permissions:

{{{
[USER_NAME]

repo2 = read
repo3 = write
}}}
https://github.com/dengzhp/hgssh2

== hgssh3 ==
'''With recent versions of mercurial, this script fails to allow read-only users to pull from a repository, see hgssh4 for an upgrade'''

A python script to control ssh access to mercurial repositories, modified from hg-ssh and hgssh2.

It allows you to specify a simple config file to define friendly/short names for repositories and access controls per user:

{{{
[reponame]
user1 = read
user2 = write
}}}
[[https://bitbucket.org/painfulcranium/hgssh3/|https://bitbucket.org/painfulcranium/hgssh3]]

== hgssh4 ==
A python script to control ssh access to mercurial repositories, modified from hg-ssh, hgssh2, and hgssh3.

It allows you to specify a simple config file to define friendly/short names for repositories and access controls per user:

{{{
[reponame]
user1 = read
user2 = write
}}}

In order to facilitate usage alongside hgweb, hgssh4 also provides a command that allows updating descriptions of remote repositories while respecting access rights.
Its usage is:
{{{
ssh $server update-desc $repository $description
}}}
where $repository is the reponame specified in the configuration file.

[[https://hg.sr.ht/~xaltsc/hgssh4|https://hg.sr.ht/~xaltsc/hgssh4]]
Line 39: Line 95:
Line 45: Line 100:

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).
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 has a private key and a corresponding entry in `authorized_keys`, the solutions presented here can 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).

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.

A step-by-step guide for adding an hg user and configuring hg-ssh can be found here. See SecuringRepositories for guidance on how to secure a Mercurial repository published via SSH.

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.

Root privileges are required to install it.

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 shared hosting like situations where you wanted to give multiple users hg access via SSH on the same SSH/unix user account.

"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. 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" 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 does not require root access.

Details at http://parametricity.net/b/hg-gateway

hgadmin

hgadmin also contains a wrapper for ssh (like "hg-ssh").

Unlike hg-ssh, this wrapper will examine the web-permissions in the managed repository to determine whether access is allowed.

hgadmin also includes a script to automatically generate the web-permissions, to manage http passwords (contained in an htpasswd file), and to manage ssh keys.

Its configuration supports users and groups and has a syntax similar to the standard svn access configuration.

hgadmin can be found at https://bitbucket.org/JakobKrainz/hgadmin

hgssh2

With recent versions of mercurial, this script fails to allow read-only users to pull from a repository

A python script to control ssh access to mercurial repositories, modified from hg-ssh.

It allows you to specify a simple config file to control the access permissions:

[USER_NAME]

repo2 = read
repo3 = write

https://github.com/dengzhp/hgssh2

hgssh3

With recent versions of mercurial, this script fails to allow read-only users to pull from a repository, see hgssh4 for an upgrade

A python script to control ssh access to mercurial repositories, modified from hg-ssh and hgssh2.

It allows you to specify a simple config file to define friendly/short names for repositories and access controls per user:

[reponame]
user1 = read
user2 = write

https://bitbucket.org/painfulcranium/hgssh3

hgssh4

A python script to control ssh access to mercurial repositories, modified from hg-ssh, hgssh2, and hgssh3.

It allows you to specify a simple config file to define friendly/short names for repositories and access controls per user:

[reponame]
user1 = read
user2 = write

In order to facilitate usage alongside hgweb, hgssh4 also provides a command that allows updating descriptions of remote repositories while respecting access rights. Its usage is:

ssh $server update-desc $repository $description

where $repository is the reponame specified in the configuration file.

https://hg.sr.ht/~xaltsc/hgssh4

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 has a private key and a corresponding entry in authorized_keys, the solutions presented here can 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


CategoryWeb CategoryHowTo

SharedSSH (last edited 2021-03-19 07:37:31 by RobinMunn)