I have such section in my ~/.hgrc config file
[auth]
repo.prefix = ssh://hguser#192.168.132.72/repos
repo.key = /home/zerkms/.ssh/mercurial-repo/id_rsa
But when I write:
hg clone ssh://hguser#192.168.132.72/repos/rps .
mercurial still requires password to enter.
What have I done wrong?
To prevent obvious questions:
Yes, there is a valid key in the specified path and it works if use it with ssh-agent.
My question is how to work with keys in [auth] section.
The following works for me (probably a new setting since the question was asked):
Add to hgrc:
[ui]
ssh = ssh -C -i ~/.ssh/id_rsa-mercurialkey
-C to enable compression, -i to specify identity file. If the key is loaded into ssh-agent, I don't get asked again for passphrase.
auth isn't for SSH. The key needs to be loaded in another way. If it were just ~/.ssh/id_rsa it would be done automatically, as it's not you may need to do something to register it. Using ~/.ssh/id_rsa is the easiest way normally - put the contents of ~/.ssh/id_rsa.pub in ~/.ssh/authorized_keys on the target machine and you're ready.
Related
I know that gpg2 uses the gpg-agent to get private-keys. Per default they are stored in ~/.gnupg/private-keys-v1.d.
Now I'm questioning myself if it's possible to instruct gpg to use another agent on another machine? The documentation is not very helpful because it does not explain how to connect your gpg to another gpg-agent. But as gpg2 requires you to use gpg-agent their is no other way to use a new keyring.
My second question is, if it's possible to instruct gpg-agent to use another dir than the default private-keys-v1.d for looking up keys?
The documentation for gpg2 also contains no option to specify a new public keyring. Is it still available although not mentioned anymore in the docs?
Greetings Sebi2020
If you are connected from machine A (e.g. your PC) to remote machine B over SSH, yes, you can instruct gpg2 on B to use gpg2 agent on A, using GnuPG Agent Forwarding (link to the gnupg manual). This is how you can use your local gpg keys on remote machines typically. Make sure you have proper versions of gnupg and OpenSSH for that (see the manual).
You may not be able to change only the subfolder name private-keys-v1.d per se, but you can replace the default gpg home directory ~/.gnupg/private-keys-v1.d with whatever_directory/private-keys-v1.d, whatever_directory being whatever directory you want to use as gpg home directory. 2 ways of doing that: set the GNUPGHOME environment variable, or use gpg --homedir option. This is still valid for gpg 2.2.4 at least. E.g. using gpg keys from a usb drive: gpg --homedir /media/usb1/gnupg ...
The options to specify a new public keyring are --keyring and --primary-keyring (use --no-default-keyring to exclude default keyring completely). Valid for gpg 2.2.4.
My gitlab is on a virtual machine on a host server. I reach the VM with a non-standard SSH port (i.e. 766) which an iptable rule then forward from host:766 to vm:22.
So when I create a new repo, the instruction to add a remote provide a mal-formed URL (as it doesn't use the 766 port. For instance, the web interface give me this:
Malformed
git remote add origin git#git.domain.com:group/project.git
Instead of an URL containing :766/ before the group.
Wellformed
git remote add origin git#git.domain.com:766/group/project.git
So it time I create a repo, I have to do the modification manually, same for my collaborator.
How can I fix that ?
In Omnibus-packaged versions you can modify that property in the /etc/gitlab/gitlab.rb file:
gitlab_rails['gitlab_shell_ssh_port'] = 766
Then, you'll need to reconfigure GitLab:
# gitlab-ctl reconfigure
Your URIs will then be correctly displayed as ssh://git#git.domain.com:766/group/project.git in the web interface.
if you configure the ssh_port correctly in config/gitlab.yml, the webpages will show the correct repo url.
## GitLab Shell settings
gitlab_shell:
...
# If you use non-standard ssh port you need to specify it
ssh_port: 766
ps.
the correct url is:
ssh://git#git.domain.com:766/group/project.git
edit: after the change you need to clear caches, etc:
bundle exec rake cache:clear assets:clean assets:precompile RAILS_ENV=production
N.B.: this was tested on an old Giltab version (v5-v6), and might not be suitable for modern instance.
You can achieve similar behavior in a 2 step process:
1. Edit: config/gitlab.yml
On the server, set the port to the one you use:
ssh_port: 766
2. Edit ~/.ssh/config
On your machine, add the following section corresponding to your gitlab:
Host sub.domain.com
Port 766
Limit
You will need to repeat this operation on each user's computer…
References
GitLab and a non-standard SSH port
Easy way to fix this issue:
ssh://git#my-server:4837/~/test.git
git clone -v ssh://git#my-server:4837/~/test.git
Reference URL
I am trying to find a way to use different ssh keys to clone different projects from bitbucket. I tried using ssh_config but I managed to define a different ssh key only for connections for a single particular host.
What I 'd like to achieve is having
Key A for bitbucket.org/myteam1/myproject
and
Key B for bitbucket.org/myteam2/myotherproject
Could help me out with this?
Finally I found out that the best solution for me is using the -e sshcommand option and inside it the -i key option to specify the private key that I want.
Far and away the easiest way to to just use ssh-agent. When you're running ssh-agent you add all you keys and it tries each of them until one works. Your OS is very possibly already running ssh-agent, so try
ssh-add /path/to/key1
ssh-add /path/to/key2
then when you try to connect if either key works you're in. If you're not running ssh-agent you can start it with (on unix/OS X):
eval $(ssh-agent)
and then add the two key files.
If for some reason you just can't bear to use ssh-agent, then I've found a workaround using a slightly tricky .ssh/config file. Something like this:
Host myteam1.bitbucket.org
Hostname bitbucket.org
HostKeyAlias bitbucket.org
IdentityFile ~/.ssh/keyA
Host myteam2.bitbucket.org
Hostname bitbucket.org
HostKeyAlias bitbucket.org
IdentityFile ~/.ssh/keyB
Then when you clone-from or push-to URLs using fake hostnames like hg clone ssh://hg#myteam2.bitbucket.org/myteam2/myproject ssh will swap in the real hostname and the right key.
But really, just use ssh-agent instead.
you can override your key on your repository hgrc level
see Configuration files for Mercurial
I have the hgeclipse plugin installed and I have a url source to go and clone from for a project that I need to begin work on. The authentication is based on ssh and my ssh key. I understand from basic googling that I need to set up a .hgr file with the path to the private. Can some one give me more pointers
Actually, you can include the path to the key in your Mercurial.ini/.hrgc file. You don't need Pageant or ssh-agent, unless you need to log in to multiple servers. If you're only ever logging in to one server, you can make your Mercurial.ini or .hgrc file have the following content:
[ui]
ssh = "TortoisePlink.exe" -ssh -2 -i "C:\Users\username\username_rsa.ppk"
This code is Windows-specific but basically, you just specify the path to the ssh program, use the -i flag and specify the path to the private key. That formula should work on all operating systems. If you're on Windows, you put that stuff in a file called "Mercurial.ini" and if you're on any other platform, it goes in a file called .hgrc
Hope this helps!
The private key must be added to ssh and not mercurial / hgrc.
You have to configure your ssh client to use your private key, but this depends greatly on the system you're using.
If you're on linux or mac os x, google some informations about using ssh-agent on your distribution.
If you're on Windows, you can use pageant for example.
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/