So I'm running Ubuntu 14.04 on VirtualBox via Vagrant, and want to set up Mercurial so that it doesn't constantly ask for a password when pulling latest. In that regard, I've installed Mercurial-Keyring, and changed my ~/.hgrc file to look like:
[extensions]
mercurial_keyring =
[auth]
ono.schemes = https
ono.prefix = <URL>
ono.username = <username>
However, now it asks me to enter a password for the encrypted keyring every time I want to use Mercurial - even on the same session.
Does anyone know what the cause of this is?
Related
I'm trying to access BitBucket from work. The only access to the Internet is via an authenticating HTTP proxy which proxies http on port 8080 and SSL on port 8070. This proxy conducts a man-in-the-middle attack on SSL connections, browsers are able to create HTTPS connections to the Internet only due to the installation of a fake Websense certificate on all clients.
I am able to connect to BitBucket using Git but not using Mercurial. I'm using Mercurial version 2.0.2.
With Git I use the following config in .gitconfig
[user]
name = Firstname Lastname
email = firstname_lastname#domain.co.uk
[http]
proxy = http://name:password#nnn.nnn.nnn.nnn:8080
And can clone a repository with the following command
D:\MercurialTesting>git clone http://Firstname_Lastname#bitbucket.org/Firstname_Lastname/bb102repo.git test1
Cloning into 'test1'...
Password for 'bitbucket.org':
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
D:\MercurialTesting>
With the addition of this config setting
[http]
sslverify = false
I can also clone the repository via the https url https://Firstname_Lastname#bitbucket.org/Firstname_Lastname/bb102repo.git
Using Mercurial though it's a different story. Using the following config in mercurial.ini
[http_proxy]
host = nnn.nnn.nnn.nnn:8080
user = firstname_lastname#domain.co.uk
passwd = password
Mercurial will access my own Mercurial server at home no problem.
D:\MercurialTesting>hg --debug clone http://nnn.nnn.nnn.nnn/hg/Workspaces/Test1
using http://nnn.nnn.nnn.nnn/hg/Workspaces/Test1
proxying through http://nnn.nnn.nnn.nnn:8080
sending capabilities command
http authorization required
realm: Mercurial Repositories
user: username
password:
http auth: user username, password *******
destination directory: Test1
query 1; heads
sending batch command
http auth: user username, password *******
requesting all changes
sending getbundle command
http auth: user username, password *******
adding changesets
changesets: 1 chunks
add changeset 711ff2c6f5b2
changesets: 2 chunks
add changeset 9034b963b4c1
. . .
Using the exact same configuration and trying to access BitBucket through Mercurial just hangs.
D:\MercurialTesting>hg --debug clone http://bitbucket.org/Firstname_Lastname/bb101repo
using http://bitbucket.org/Firstname_Lastname/bb101repo
proxying through http://nnn.nnn.nnn.nnn:8080
sending capabilities command
abort: error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
D:\MercurialTesting>
Using the same configuration with SSL via the url https://bitbucket.org/Firstname_Lastname/bb101repo Mercurial hangs in exactly the same way. During this process Wireshark detects no network activity at all.
Changing the settings in Mercurial.ini to match the port which the proxy serves SSL through has no effect. Setting the environment variable http_proxy makes no difference, but setting the environment variable https_proxy changes the output completely. Setting https_proxy and adding --insecure to the hg command invocation results in:
D:\MercurialTesting>hg --debug clone http://bitbucket.org/Firstname_Lastname/bb101repo --insecure
using http://bitbucket.org/Firstname_Lastname/bb101repo
proxying through http://nnn.nnn.nnn.nnn:8080
sending capabilities command
warning: bitbucket.org certificate with fingerprint 79:ce:0d:30:b0:17:29:6a:d1:9f:dd:d3:62:80:70:28:5e:9f:c2:e3 not verified (check hostfingerprints or web.cacerts config setting)
http authorization required
realm: Bitbucket.org HTTP
user: Firstname_Lastname
password:
http auth: user Firstname_Lastname, password ***
warning: bitbucket.org certificate with fingerprint 79:ce:0d:30:b0:17:29:6a:d1:9f:dd:d3:62:80:70:28:5e:9f:c2:e3 not verified (check hostfingerprints or web.cacerts config setting)
abort: HTTP Error 502: Success
D:\MercurialTesting>
And now Wireshark does detect an exchange taking place between my workstation and the proxy server. What I find most confusing though is that it doesn't make the slightest difference what I set https_proxy to, hg always uses the http proxy setting from Mercurial.ini and produces the same output above irrespective of whether I set https_proxy to the correct details for the SSL proxy or to complete garbage. The only difference is that if the environment variable https_proxy isn't set at all then hg just hangs as described above.
The formats for https_proxy I've tried include all variations of:
https_proxy=ip.ip.ip.ip:8070
https_proxy=ip.ip.ip.ip:8080
https_proxy=username:password#ip.ip.ip.ip:8070
https_proxy=username:password#ip.ip.ip.ip:8080
https_proxy=http://ip.ip.ip.ip:8070
https_proxy=http://ip.ip.ip.ip:8080
https_proxy=http://username:password#ip.ip.ip.ip:8070
https_proxy=http://username:password#ip.ip.ip.ip:8080
The results are the same no matter what I set it to.
So the questions I could really use some help with are:
How come I can access my Mercurial repositories at home but not at BitBucket?
How come I can access BitBucket with Git but not with Mercurial using the same configuration?
Does anyone have any ideas of how I can get this to work or what I can test next?
I am also connecting via proxy to bitbucket. As my settings didn't work as expected I found this SO entry.
I noticed that if I use command line parameters then everything works.
hg --config http_proxy.host=192.168.1.1:8080 --config http_proxy.user=Vad1mo --config http_proxy.passwd=secret clone https://bitbucket.org/Vadimo/test
On the other hand same entries in Mercurial.ini didn't work.
[http_proxy]
host = 192.168.1.1
port = 8080
user = Vad1mo
passwd = internet
By accident I found out the tiny difference between CMD and ini. In CMD the port is postfixed to the host. In ini file it is a new entry.
Changing mercurial.ini to postfix the port to host like on command line solved the problem.
[http_proxy]
host = 192.168.1.1:8080
;port = 8080
user = Vad1mo
passwd = internet
Maybe this also will help you.
btw. my hg version is 2.6.3
I ran into a similar problem with my work's proxy- actually, almost identical.
I've gotten around the problem so far by setting the http_proxy in mercurial.ini and then connecting to BitBucket via their HTTP address hg.io.
For example, my repository at https://bitbucket.org/mattgwagner/mattgwagner.com can be accessed via http://hg.io/mattgwagner/mattgwagner.com . Of course, this will send your password and connection in plaintext, but at least it let me connect.
This came in more use for me when pulling in open source projects hosted on BitBucket for my use.
Mercurial.ini
[http_proxy]
host = 192.168.1.155:8080
no =
user = domainUsername
passwd = pass
Are you able to ssh out? Bitbucket supports ssh access and your proxy won't muck w/ that if it's allowed.
I have hgweb.wsgi setup on an ubuntu server under apache2. Furthermore I have basic authing using the apache2 htpasswd approach. This all works nicely. However, we want to control what each user have access to and ACL seems to be the best approach. So inside the repos .hg folder I've created a hgrc and modified it according to the documentation for getting ACL up and running ( I've also enabled the extension ). The problem is I get no indication that the hgrc is used at all. If I add [ui] debug = true I still get nothing from the remote client. Sadly I'm not quite sure how to go about debugging this so any help would be much appreciated.
To make sure that a .hg/hgrc file in a repository is being consulted add something noticable to the [web] section like:
[web]
description = Got this from the hgrc
style = coal
name = RENAMED
If you don't see those in the web interface your .hg/hgrc isn't being consulted, and the most common reason for that is -- permissions. Remember that the .hg/hgrc has to owned by a user or group that is trusted by the webserver user (usually apache or www-data or similar). If apache is running under the user apache then chown the .hg/hgrc file over to apache for ownership -- root won't do and htpasswd user is irrelevant.
If that file is being consulted then you need to start poking around in the apache error logs. Turning on debug and verbose will put more messages into the apache error log, not into the remote client's output.
The repository is owned by user root, and group dev
Another user is running hg update on the repository and getting the following messages:
Not trusting file /dev/.hg/hgrc from untrusted user root, group dev
Not trusting file .hg/hgrc from untrusted user root, group dev
Not trusting file /dev/.hg/hgrc from untrusted user root, group dev
Not trusting file /dev/.hg/hgrc from untrusted user root, group dev
abort: Permission denied: /dev/src/backend/java/com/tt/afr/schedule/service/ScheduleComparator.java
In /etc/mercurial/hgrc, we have:
trusted.users=root
In the home directory of user running hg update, we have this hgrc file:
[trusted]
users = root
groups = dev
User is connecting to server using ssh and running the commands.
What can we do to fix this?
Please read the help on trust in Mercurial and make sure that you've added the trust settings on the server. When you connect over SSH, it does not matter who you trust or don't trust locally — it's the hg binary that you run on the server (via the SSH tunnel) that needs to trust the config file.
Also note that you need to put
[trusted]
users = root
in the /etc/mercurial/hgrc file on the server. The section.key = name syntax we use when talking about configuration settings only work on the command line.
For everybody else who has added this solution to their /repo/.hg/hgrc and nothing happened, this solution worked for me:
https://j.ee.washington.edu/trac/gmtk/ticket/33
Add in /etc/mercurial/hgrc.d/trust.rc
[trusted]
groups = yourgroup
users = youruser
Essentially, writing permissions to /repo/.hg/hgrc will not work, because the file itself is owned by an untrusted user.
Based on the answer by DustWolf, this works on Ubuntu under WSL (Windows Subsystem for Linux) using a Windows drive letter share mounted using Microsoft's WSL drvfs file system driver, i.e., hg running locally on a shared drive.
not trusting file /mnt/x/repo/.hg/hgrc from untrusted user root, group root
Mercurial Distributed SCM (version 5.3.1)
(see https://mercurial-scm.org for more information)
Copyright (C) 2005-2020 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Create trust.rc on the WSL machine:
sudo touch /etc/mercurial/hgrc.d/trust.rc
sudo nano /etc/mercurial/hgrc.d/trust.rc
Add:
[trusted]
groups = root
users = root
Save trust.rc and hg should now trust the repo hgrc as WSL's drvfs driver mounts the share as root:root.
wsl wsl-drvfs
Not your case, but might be worth a hint:
I had this error in a local container that was setup to migrate repos from hg to GitLab. Solved it by just by changing the ownership of the .hg directory in the downloaded hg's repository folder to root user/group:
chown -R root:root .hg
And the message not trusting file /data/hg-repo/.hg/hgrc from untrusted user 1000, group 1000 was gone.
Has anybody else had an issue with the new Intellij HG4IDEA not working in Windows? Whenever I try to pull from a remote repository it just hangs, never asking for my ssh username/password.
My initial thought was that I should set my username/password in mercurial.ini somehow.
It just sits like this indefinably, if I try to cancel it it will not stop.
You need to configure it to work with your keys without password or
use ssh client that is able to ask password in a dialog window, like
TortoisePlink.exe.
When using console SSH client, there is no way for IDEA to see if it's
requesting passwords and provide them (it's just not supported, so ssh
client must either work without asking anything in the console or ask
a password via dialog).
See also
http://youtrack.jetbrains.net/issue/IDEA-62230 and http://youtrack.jetbrains.net/issue/IDEA-56004.
In order to get Intellij 10 to work with hg4idea I just changed my mercurial.ini file in my user directory of windows.
# Generated by TortoiseHg setting dialog
[extensions]
hgext.convert=
[ui]
username = myusername
[trusted]
users = *
groups = *
[ui]
ssh="C:\Program Files\TortoiseHg\bin\TortoisePlink.exe"
The key was to set ssh= to a client that supports prompting for passwords.
I use mercurial in my project, and every time I push new changesets to the server by ssh, it ask me for a password.
Then how to config the mercurial to push with out asking password?
I works on Ubuntu 9.10
On Linux and Mac, use ssh-agent.
Ensure you have an ssh keypair (see man ssh-keygen for details)
Copy your public key (from ~/.ssh/id_dsa.pub) to the remote machine, giving it a unique name (such as myhost_key.pub)
Log in to the remote machine normally and append the public key you just copied to the ~/.ssh/authorized_keys file
Run ssh-add on your local workstation to add your key to the keychain
You can now use any remote hg commands in this session without requiring authentication.
Assuming you're using Windows, have a read of my Mercurial/SSH guide. Down the bottom of the post you'll find info on how to use PuTTy to do this for you.
Edit: -- Here's the part of the post that I'm talking about (bear in mind you'll need to have pageant running with your key already loaded for this to work):
Client: Setting up Mercurial
If you haven't already, make sure you install Mercurial on the client machine using the default settings. Make sure you tell the installer to add the Mercurial path to the system PATH.
The last step of configuration for the client is to tell Mercurial to use the PuTTy tools when using SSH. Mercurial can be configured by a user-specific configuration file called .hgrc. On Windows it can also be called Mercurial.ini. The file is located in your home folder. If you don't know what your home folder is, simply open a command prompt and type echo %USERPROFILE% - this will tell you the path.
If you haven't set up your configuration yet, then chances are the configuration file doesn't exist. So you'll have to create it. Create a file call either .hgrc or Mercurial.ini in your home folder manually, and open it in a text editor. Here is what part of mine looks like:
[ui]
username = OJ Reeves
editor = vim
ssh = plink -ssh -i "C:/path/to/key/id_rsa.ppk" -C -agent
The last line is the key and this is what you need to make sure it set properly. We are telling Mercurial to use the plink program. This also comes with PuTTy and is a command-line version of what the PuTTY program itself does behind the scenes. We also add a few parameters:
-ssh : Indicates that we're using the SSH protocol.
-i "file.ppk" : Specifies the location of the private key file we want to use to log in to the remote server. Change this to point to your local putty-compatible ppk private key. Make sure you user forward-slashes for the path separators as well!
-C : This switch enables compression.
-agent : This tells plink to talk to the pageant utility to get the passphrase for the key instead of asking you for it interactively.
The client is now ready to rock!
Install PuTTY.
If you're on Windows, open projectdir/.hg/hgrc in your favorite text editor. Edit it to look like this:
[paths]
default = ssh://hg#bitbucket.org/name/project
[ui]
username = Your Name <your#email.com>
ssh = "C:\Program Files (x86)\PuTTY\plink.exe" -ssh -i "C:\path\to\your\private_key.ppk" -C -agent
If it's taking forever to push, the server might be trying to ask you a question (but it's not displayed).
Run this:
"C:\Program Files (x86)\PuTTY\plink.exe" -T hg#bitbucket.org -i "C:\Program Files (x86)\PuTTY\plink.exe" -ssh -i "C:\path\to\your\private_key.ppk"
Answer any questions, and then try pushing again.
If you're using Bitbucket, open your private key with puttygen, copy your public key out of the top textbox, and add it to your user account: https://bitbucket.org/account/user/USERNAME/ssh-keys/