How to save username and password with Mercurial?
Asked Answered
B

8

277

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?

Buttonwood answered 6/4, 2010 at 11:28 Comment(0)
C
336

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.

Chequer answered 7/4, 2010 at 0:12 Comment(4)
Why doesn't this work when the server is: ssh://HGSERVER ? the "ssh://username:password@HGSERVER" format doesn't work either..Elohist
@Elohist -- look at the below comment -- if you are using SSH, why not use key-based login?Kellam
@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.Acquiescent
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).Bodiless
A
170

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

Acquiescent answered 6/4, 2010 at 11:31 Comment(13)
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.Buttonwood
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).Blender
@Chris, you're missing some <>Sacculus
@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.Acquiescent
Method 2 is really the only way to handle things securely and maintain user-level permissions on the remote system.Bloodline
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.Penmanship
@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.Bloodline
@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.Penmanship
@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.Bloodline
+1 Nice answer! I think they should be reordered like 2, 3, 1 :)Bumblebee
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?Babirusa
@Babirusa 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?Acquiescent
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.Babirusa
P
65

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

Plus answered 11/1, 2011 at 1:3 Comment(7)
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.Greene
I also second @Greene for seconding me!Mlawsky
On Windows at least TortoiseHg supports keyring extension: Global Settings -> Extensions -> mercurial_keyringInsouciant
Unfortunately currently the keyring extension has a bug on Windows where it can only save one password at a time. See this question.Chequer
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.Chuipek
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 rootPicardi
Also you should set [auth] default.prefix = https://hgrepo/ default.username = username in ~/.hgrcGovan
M
30

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/

Mahler answered 6/4, 2010 at 11:39 Comment(4)
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.Buttonwood
You might want to use --debug and --verbose options for hg push to see what is going wrong...Mahler
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 forClandestine
Assuming you have the luxury of a device which you can get the public key off of, of course.Dyspeptic
A
25

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

Absher answered 11/1, 2013 at 2:24 Comment(0)
B
4

mercurial_keyring installation on Mac OSX using MacPorts:

sudo port install py-keyring
sudo port install py-mercurial_keyring

Add the following to ~/.hgrc:

# Add your username if you haven't already done so.
[ui]
username = [email protected]

[extensions]
mercurial_keyring =
Brambling answered 21/9, 2012 at 9:38 Comment(2)
I get "no module named mercurial_keyring" in TortoiseHg after running these commands and updating my .hgrc file.Galasyn
Make sure you have the right Python version, as described here: #5173697Spa
W
2

If you are using TortoiseHg you have to perform these three steps shown in the attached screen shot, this would add your credentials for the specific repository you are working with.

enter image description here

To add global settings you can access the file C:\users\user.name\mercurial.ini and add the section

[auth]
bb.prefix=https://bitbucket.org/zambezia/packagemanager
bb.username = $username
bb.password = $password

Hope this helps.

Welldone answered 19/7, 2017 at 6:50 Comment(0)
T
0

While it may or may not work in your situation, I have found it useful to generate a public / private key using Putty's Pageant.

If you are also working with bitbucket (.org) it should give you the ability to provide a public key to your user account and then commands that reach out to the repository will be secured automatically.

If Pageant doesn't start up for you upon a reboot, you can add a shortcut to Pageant to your Windows "Start menu" and the shortcut may need to have a 'properties' populated with the location of your private (.ppk) file.

With this in place Mercurial and your local repositories will need to be set up to push/pull using the SSH format.

Here are some detailed instructions on Atlassian's site for Windows OR Mac/Linux.

You don't have to take my word for it and there are no doubt other ways to do it. Perhaps these steps described here are more for you:

  1. Start PuttyGen from Start -> PuTTY-> PuttyGen
  2. Generate a new key and save it as a .ppk file without a passphrase
  3. Use Putty to login to the server you want to connect to
  4. Append the Public Key text from PuttyGen to the text of ~/.ssh/authorized_keys
  5. Create a shortcut to your .ppk file from Start -> Putty to Start -> Startup
  6. Select the .ppk shortcut from the Startup menu (this will happen automatically at every startup)
  7. See the Pageant icon in the system tray? Right-click it and select “New session”
  8. Enter username@hostname in the “Host name” field
  9. You will now log in automatically.
Tall answered 24/8, 2016 at 11:52 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.