Using ssh with hg

These are some brief notes on using ssh with Mercurial. NOTE: This article has been rewritten in light of recent experience.

I used to access my old cvs environment using ssh. My projects were all setgid to a common “cvs” user.

When setting up a similar environment for Mercurial I did things slightly differently (find my previous article on converting from cvs to hg here).

1. Created an hg user on my server whose home was /home/hg.

2. Set up a completely separate directory, /data/share/hg, to hold the existing hg repositories and made the new hg user the owner of the whole thing.

3. Symlinked each of the directories in /data/share/hg back to /home/hg.

4. Signed in as hg and generated a keypair with ssh-keygen, copying the public key to authorized_keys under the same .ssh directory.

5. Renamed hg’s private and public keys and downloaded to my own account’s .ssh directory (in my case I made them hg_rsa and, respectively).

6. Created a new config file under my own .ssh with the following text:

Host hgserver
   User hg
   IdentityFile ~/.ssh/hg_rsa

6. Created a local hg directory under my own $HOME and cloned a repository from the remote server:

hg clone ssh://hgserver/myproject

7. Verified that the .hg/hgrc in each local repository contained the following:

default = ssh://hgserver/myproject

The advantages of doing things this way are:

(a) multiple users can work on the remote repository using the same account, thus avoiding issues of file ownership that can occur when many different user accounts are modifying files in the same directory;

(b) the “default” path is optimally short, reducing the possibility of errors when copying into the hgrc files of multiple local repositories;

(c) The repo can still be published over HTTP by installing and configuring the hgweb.cgi script (if you put the repo under hg’s home directory permissioning it for HTTP would break access using ssh keys, and vice-versa). This last bit is important because it will be the subject of my next article on hg.