Mercurial_ The Definitive Guide - Bryan O'Sullivan [46]
You might have forgotten to use ssh-add or pageant to store the passphrase.
You might have stored the passphrase for the wrong key.
If you’re being prompted for the remote user’s password, there are a few other possible problems to check:
Either the user’s home directory or his .ssh directory might have excessively liberal permissions. As a result, the ssh daemon will not trust or read his authorized_keys file. For example, a group-writable home or .ssh directory will often cause this symptom.
The user’s authorized_keys file may have a problem. If anyone other than the user owns or can write to that file, the ssh daemon will not trust or read it.
In an ideal world, you should be able to run the following command successfully, and it should print exactly one line of output, the current date and time.
ssh myserver date
If, on your server, you have login scripts that print banners or other junk even when running non-interactive commands like this, you should fix them before you continue, so that they only print output if they’re run interactively. Otherwise these banners will at least clutter up Mercurial’s output. Worse, they could potentially cause problems with running Mercurial commands remotely. Mercurial tries to detect and ignore banners in non-interactive ssh sessions, but it is not foolproof. (If you’re editing your login scripts on your server, the usual way to see if a login script is running in an interactive shell is to check the return code from the command tty -s.)
Once you’ve verified that plain old ssh is working with your server, the next step is to ensure that Mercurial runs on the server. The following command should run successfully:
ssh myserver hg version
If you see an error message instead of normal hg version output, this is usually because you haven’t installed Mercurial to /usr/bin. Don’t worry if this is the case; you don’t need to do that. But you should check for a few possible problems:
Is Mercurial really installed on the server at all? I know this sounds trivial, but it’s worth checking!
Maybe your shell’s search path (usually set via the PATH environment variable) is simply misconfigured.
Perhaps your PATH environment variable is only being set to point to the location of the hg executable if the login session is interactive. This can happen if you’re setting the path in the wrong shell login script. See your shell’s documentation for details.
The PYTHONPATH environment variable may need to contain the path to the Mercurial Python modules. It might not be set at all; it could be incorrect; or it may be set only if the login is interactive.
If you can run hg version over an ssh connection, well done! You’ve got the server and client sorted out. You should now be able to use Mercurial to access repositories hosted by that username on that server. If you run into problems with Mercurial and ssh at this point, try using the --debug option to get a clearer picture of what’s going on.
Using Compression with ssh
Mercurial does not compress data when it uses the ssh protocol, because the ssh protocol can transparently compress data. However, the default behavior of ssh clients is not to request compression.
Over any network other than a fast LAN (even a wireless network), using compression is likely to significantly speed up Mercurial’s network operations. For example, over a WAN, someone measured compression as reducing the amount of time required to clone a particularly large repository from 51 minutes to 17 minutes.
Both ssh and plink accept a -C option, which turns on compression. You can easily edit your ~/.hgrc to enable compression for all of Mercurial’s uses of the ssh protocol. Here is how to do so for regular ssh on Unix-like systems, for example.
[ui]
ssh = ssh -C
If you use ssh on