Trouble getting to work Mercurial with Shared SSH

[Paul Boddie]

Pablo Olmos de Aguilera C. wrote:
> Yep, It could work the problem is that I'm using a shared hosting in
> dreamhost, so I haven't root access. I could install mercurial because
> it had a special argument to compile it and install it from my home.
>   

In principle, with mercurial-server, I don't see why one couldn't 
dedicate an existing user (rather than an 'hg' user) to the task of 
giving access to your repositories.

> So, I'm wrong about what hg-ssh and hg-login are supposed to do?
> (maybe I'm looking the wrong place!)
>   

These solutions seem to be concerned with sharing one system account, 
where such accounts are normally the smallest "unit of authentication". 
The use of the command option in the authorized_keys file should also 
provide a means of further restricting access. I don't think you've 
misunderstood this - you probably understand it better than I do. :-)

> Another thing that could work could be that somehow configure ssh
> itself through authorized_keys (or some kind of ssh config) to
> disallow that particular user to input any command, but only from the
> other "keys".
>   

As far as I can tell, you would enter a specific command for each of the 
keys in the authorized_keys file (which is what you appeared to do). 
According to the manual page for sshd, the last stage in the login 
process is to invoke either the user's shell (which would be your 
hosting user's shell, I suppose) or the command, which in the case of 
hg-ssh would lead to an hg serve session being initiated. Unless hg 
serve allows arbitrary command execution, those users whose keys are 
accompanied by hg-ssh commands shouldn't be able to fully access your 
server.

Paul

P.S. If you don't have any problems with administering Web-based 
solutions, it should be possible to export your repositories using 
something like hgwebdir and managing the users individually via other 
mechanisms:

http://mercurial.selenic.com/wiki/PublishingRepositories#Adding_Authentication

However, it can certainly be argued that this adds a degree of 
administrative overhead that you would avoid by just using the existing 
SSH mechanisms: using HTTPS explicitly, dealing with certificates, and 
so on.