How to save username and password with Mercurial?

mercurial hgrc

177,145

Solution 1

You can make an auth section in your .hgrc or Mercurial.ini file, like so:

[auth]
bb.prefix = https://bitbucket.org/repo/path
bb.username = foo
bb.password = foo_passwd

The ‘bb’ part is an arbitrary identifier and is used to match prefix with username and password - handy for managing different username/password combos with different sites (prefix)

You can also only specify the user name, then you will just have to type your password when you push.

I would also recommend to take a look at the keyring extension. Because it stores the password in your system’s key ring instead of a plain text file, it is more secure. It is bundled with TortoiseHg on Windows, and there is currently a discussion about distributing it as a bundled extension on all platforms.

Solution 2

There are three ways to do this: use the .hgrc file, use ssh or use the keyring extension

1. The INSECURE way - update your ~/.hgrc file

The format that works for me (in my ~/.hgrc file) is this

[ui]
username=Chris McCauley <[email protected]>

[auth]
repo.prefix = https://server/repo_path
repo.username = username
repo.password = password

You can configure as many repos as you want by adding more triplets of prefix,username, password by prepending a unique tag.

This only works in Mercurial 1.3 and obviously your username and password are in plain text - not good.

2. The secure way - Use SSH to AVOID using passwords

Mercurial fully supports SSH so we can take advantage of SSH's ability to log into a server without a password - you do a once off configuration to provide a self-generated certificate. This is by far the safest way to do what you want.

You can find more information on configuring passwordless login here

3. The keyring Extension

If you want a secure option, but aren't familiar with SSH, why not try this?

From the docs ...

The extension prompts for the HTTP password on the first pull/push to/from given remote repository (just like it is done by default), but saves the password (keyed by the combination of username and remote repository url) in the password database. On the next run it checks for the username in .hg/hgrc, then for suitable password in the password database, and uses those credentials if found.

There is more detailed information here

Solution 3

No one mentioned the keyring extension. It will save the username and password into the system keyring, which is far more secure than storing your passwords in a static file as mentioned above. Perform the steps below and you should be good to go. I had this up and running on Ubuntu in about 2 minutes.

>> sudo apt-get install python-pip
>> sudo pip install keyring
>> sudo pip install mercurial_keyring

**Edit your .hgrc file to include the extension**
[extensions]
mercurial_keyring =

https://www.mercurial-scm.org/wiki/KeyringExtension

Solution 4

A simple hack is to add username and password to the push url in your project's .hg/hgrc file:

[paths]
default = http://username:[email protected]/myproject

(Note that in this way you store the password in plain text)

If you're working on several projects under the same domain, you might want to add a rewrite rule in your ~/.hgrc file, to avoid repeating this for all projects:

[rewrite]
http.//mydomain.com = http://username:[email protected]

Again, since the password is stored in plain text, I usually store just my username.

If you're working under Gnome, I explain how to integrate Mercurial and the Gnome Keyring here:

http://aloiroberto.wordpress.com/2009/09/16/mercurial-gnome-keyring-integration/

Solution 5

NOBODY above explained/clarified terms to a novice user. They get confused by the terms

.hg/hgrc -- this file is used for Repository, at local/workspace location / in actual repository's .hg folder.

~/.hgrc -- this file is different than the below one. this file resides at ~ or home directory.

myremote.xxxx=..... bb.xxxx=......

This is one of the lines under [auth] section/directive, while using mercurial keyring extension. Make sure the server name you put there, matches with what you use while doing "hg clone" otherwise keyring will say, user not found. bb or myremote in the line below, are "alias name" that you MUST give while doing "hg clone http:/.../../repo1 bb or myremote" otherwise, it wont work or you have to make sure your local repository's .hg/hgrc file contain same alias, ie (what you gave while doing hg clone .. as last parameter).

PS the following links for clear details, sorry for quickly written grammar.

ex: If inside ~/.hgrc (user's home directory in Linux/Unix) or mercurial.ini in Windows at user's home directory, contains, the following line and if you do

`"hg clone http://.../.../reponame myremote"`

, then you'll never be prompted for user credentials more than once per http repo link. In ~/.hgrc under [extensions] a line for "mercurial_keyring = " or "hgext.mercurial_keyring = /path/to/your/mercurial_keyring.py" .. one of these lines should be there.

[auth]
myremote.schemes = http https
myremote.prefix = thsusncdnvm99/hg
myremote.username = c123456

I'm trying to find out how to set the PREFIX property so that user can clone or perform any Hg operations without username/password prompts and without worrying about what he mentioned in the http://..../... for servername while using the Hg repo link. It can be IP, servername or server's FQDN

View more solutions

177,145

satoru

Curious programmer.

Updated on November 06, 2020

Comments

satoru over 3 years
I used Mercurial in a personal project, and I have been typing my username and password every time I want to push something to the server.

I tried adding the following to the .hgrc file in my home directory, but it seems to be completely ignored.
```
[ui]
username = MY_USER_NAME
password = MY_PASSWORD
```
How to do this the right way?
satoru about 14 years

Mine is similar to yours. My repository is on Google Code, I saved the auto-generated password with my username in ~/.hgrc but it doesn't work.
Tomislav Nakic-Alfirevic about 14 years

Satoru, Chris is not talking about mercurial, but about ssh: ssh can be set up so that you don't have to identify yourself using a password (as described e.g. here: debian-administration.org/articles/152).
satoru about 14 years

I have downloaded the extension, however, when I tried to make a push the password prompt refuses to let me pass :( May be I have done it the wrong way. I have never used Gnome Keyring before. Thank you all the same.
tonfa about 14 years

@Chris, you're missing some <>
Roberto Aloi about 14 years

You might want to use --debug and --verbose options for hg push to see what is going wrong...
Chris McCauley about 14 years

@Tomislav - Thanks for the comment it made my realise that I could have been more clear. I'm talking about a pretty standard usage scenario for Mercurial.
Peter Rowell almost 14 years

Method 2 is really the only way to handle things securely and maintain user-level permissions on the remote system.
Oren over 13 years

Why doesn't this work when the server is: ssh://HGSERVER ? the "ssh://username:password@HGSERVER" format doesn't work either..
David Eads over 13 years

@Oren -- look at the below comment -- if you are using SSH, why not use key-based login?
Draemon about 13 years

user570626's answer of using keyring integration is much better than either of these. @Peter Rowell: ssh setup is a real pain if you have a few users and repositories; you need local unix users and have to muck about with restricting the commands that can be run with .ssh/authorized_keys and a shell wrapper. Not exactly a clean solution.
Peter Rowell about 13 years

@Draemon: 1. user570626's answer was given 7 months after my comment was made. 2. It does not appear to be a general solution that can be used on the wildly varying host environments I have to deal with. 3. "mucking about" sounds like you have had problems dealing with Unix/Linux. I've been at a shell prompt since 1980 and I'm quite comfortable there. On any given day I may do work on 10 different sites; in a month maybe 25 different sites. The one constant I have is that all of these sites permit some sort of SSH connection, and so that's what my workflow is based on.
Draemon about 13 years

@Peter Rowell: 1. what difference does that make? I said his solution was better not sooner. 2. It has nothing to do with the hosting environment, it's purely client side (unlike your SSH solution which requires changes on the server side to support it). 3. Glossing over the trolling and boasting, I still say that it's not a clean solution. You need a local user and you have to give them shell access then restrict that. Shell access isn't always a sensible option. I'm surprised that someone of your experience hasn't come across a sysadmin who didn't want to give your service shell access.
Peter Rowell about 13 years

@Draemon: I guess we have different experiences. Personally, I will not work on a system where I don't have a shell prompt. It makes me completely dependent on the other system to already have installed what I need. My general experience is that if I can't get a prompt, I almost certainly can't get other services I consider to be fundamental to my workflow. Different (key)strokes for different folks.
ngeek almost 13 years

This is my favorite solution. ... and just to second what @hadrien said, after the described three actions it works like a charm on Mac OS X.
Hadrien almost 13 years

I also second @ngeek for seconding me!
user272735 over 12 years

On Windows at least TortoiseHg supports keyring extension: Global Settings -> Extensions -> mercurial_keyring
Laurens Holst over 12 years

Unfortunately currently the keyring extension has a bug on Windows where it can only save one password at a time. See this question.
Isaac over 12 years

This seems like the best solution, but when I try to use it on OSX, python segfaults when trying to get the password from the keychain.
Ramchandra Apte almost 12 years

This is the best solution - because it uses the keyring. Otherwise you would have to run sudo hg push and keep the .hgrc file owned by root
wim about 11 years

+1 Nice answer! I think they should be reordered like 2, 3, 1 :)
beauXjames about 10 years

perfect for the case at hand...if you're using ssh, you don't need to pass in a password...that's what the keys a for
Dunc over 9 years

I get "no module named mercurial_keyring" in TortoiseHg after running these commands and updating my .hgrc file.
David Given about 9 years

Assuming you have the luxury of a device which you can get the public key off of, of course.
phm almost 9 years

Make sure you have the right Python version, as described here: stackoverflow.com/questions/5173197/…
Chris McCauley almost 7 years

@santafebound As the text says, its "arbitrary" and is used only to associate the username and password with the prefix so provide any tag that makes sense to you.
Jasper almost 6 years

I really wouldn't recommend storing passwords in plain text (which is what this answer does, even if it does also briefly mention a better alternative).
RPM over 5 years

I already have #2 setup and can ssh into the mercurial server without a password, however I cannot do a passwordless hg pull from that server. Any idea why?
Chris McCauley over 5 years

@RPM Are you using the same username to ssh in and to do the hg pull? Have you checked that credentials aren't being passed via ssh-agent or via the local config file?
RPM over 5 years

It was the same credentials however I figured out the issue - the mercurial repo was setup using a different alias to the server name than the one I setup passwrodless ssh for. I just had to add an entry in .ssh/config to use that identitiy file for that alias. Once I did that it worked just fine. e.g. My key was setup for merc.id identity file for server m1. My mercurial was setup for the fully qualified name m1.somecompany.com. Once I added m1.somecompany.com to my .ssh/config file and set teh IdentityFile to the same merc.id file everything worked fine.
Marat Gareev about 5 years

Also you should set [auth] default.prefix = https://hgrepo/ default.username = username in ~/.hgrc