I've been trying to get SourceTree to communicate with my company's Mercurial remote repository but I seem to be failing. On the command line, I can get hg pull working just fine (it authenticates with my id_rsa private key without any trouble), but when I try to pull through the UI, it just spins. I have an embedded Mercurial install as well as a separate hg install on the command line.
So, the issue, as it turns out, has to do with the SSH client configuration in the settings. While Git can use any SSH keys available, Mercurial requires the SSH key to be in ppk format. The good news is that this is available through Tools > Create or Import SSH Keys. This will launch PuTTY Key Generator.
Click "Load" and then set the dropdown for file types to ".".
Navigate to the location of the private key file and load id_rsa or similar.
Click "Save private key". This will output the ppk file.
Go back to SourceTree and choose Tools > Options
Set the SSH client to Putty/Plink.
Browse for the ppk file you just created.
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.
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/
I use GVIM on Ubuntu 9.10. I'm looking for the right way to configure GVIM to be able to edit remote files (HTML, PHP, CSS) by for exemple ftp.
When i use :e scp://username#remotehost/./path/to/file i get: error detected while processing BufEnter Auto commands for "*":E472: Command failed.
When i open a file on remote via Dolphin or Nautilus, i cannot use other files with NERDTree.
Finally when i edit on remote a file via Dolphin the rights are changing to access interdit.
So how to use GVIM to edit remote files like on my localhost?
I've found running the filesystem over ssh (by means of sshfs) a better option than having the editor handle that stuff or running the editor itself over an ssh tunnel.
So you need to
apt-get install sshfs
and then
sshfs remoteuser#remotehost:/remote/path /local/mountpoint
And that will let you edit your remote files as if they were on your local file system.
To make it even smoother you can add a line to /etc/fstab
sshfs#remoteusername#remotehost:/remote/path /local/mountpoint fuse user,noauto
For some reason I find that I have to use fusermount -u /local/mountpoint rather then just umount /local/mountpoint when experimenting with this. Maybe that's just my distro.
Recently I've also noted that the mounting user must be in the fuse group. So:
sudo addgroup <username> fuse
An other popular option of course, would be to run vim (rather then gvim) inside a GNU Screen session on one machine and connect to that session via ssh from wherever you happen to be. Code along all day at work and in the evening you ssh into your office computer, reattach to your gnu screen session and pick up exactly where you left off. I used find the richer color palette to be the only thing I really missed from gvim when using vim, but that can actually be fixed thanks to a fork of urxvt that will let you customize the entire 256 position color palette, not just the 16 first positions of the palette that most terminal emulators will let you customize.
There is one way and that is using the remote host's copy, using SSH to forward the X11 client to you, like so:
user#local:~/$ ssh -X user#host
...
user#host:~/$ gvim file
The latter command should open gvim on your desktop. Of course, this relies on the remote host having X11 / gnome / gvim installed in the first place, which might not be the solution you're looking for / an option in your case.
Note: X11 forwarding can be a security risk.
In order for netrw to work seamlessly, I believe you need to not be in compatibility mode.
Try
:set nocompatible
then
:edit scp://host/path/to/file
Try this
:e scp://username#remotehost//path/to/file
Note that the use of // is intentional after remotehost it gives the absolute path of your file
:)
http://www.celsius1414.com/2009/08/19/how-to-edit-remote-files-with-local-vim/
The vim tips wiki has an article on this, Editing remote files via scp in vim.
EDIT: Key authentication is not necessary for opening files over ssh. Vim will prompt for password.
It would be useful to note if netrw.vim was loaded by vim when it started.
:echo exists("g:loaded_netrwPlugin")
For opening files over ssh, you need your local machine's public key in the server's authorized keys. Following help section in vim documentation explains it pretty well.
:help netrw-ssh-hack
Quick way to export public key would be by using ssh-copy-id (if available).
ssh-copy-id user#host
And have a look at netrw documentation for network file editing over other protocols.
:help netrw
HTH.
According to the docs BufEnter is processed after the file has been read and the buffer created, so my guess is that netrw successfully read the file but you have a plugin that assumes the file is on the local filesystem and is trying to access it, e.g. to run ctags.
Try disabling all your plugin scripts except the default Vim ones, and then editing the file.
Also, try editing a directory to see if netrw can read that - you need to put the / on the end so that netrw knows it is a dir.
About your command, :e scp://username#remotehost/./path/to/file : note that with netrw, scp is taken relative to your home directory on that remote host. To avoid home-relative pathing, drop that "."; ie. :e scp://username#remotehost//path/to/file .
to accomplish this on windows download/install the Dokan library and Dokan SSHFS, which are the first and last links on this page.
I didn't think you were going to be able to directly edit a remote file using GVIM running locally. However, as others have pointed out, this is defintiely possible. This looks very interesting; I will check this out. I will leave the rest of my post up here, in case it is useful to anyone else, as an alternative method. This method will work even if you don't have SSH access to the file (ie, you only have FTP, or S3, or whatever).
You may get that effect, though, by tying GVIM into a graphical file transfer application. For example, on OS X, I use CyberDuck to transfer files (FTP, SFTP, etc). Then, I have it configured to use GVIM as my editor, so I can just double-click on a file in the remote listing, and CyberDuck will download a copy of that remote file, and open it in GVIM. When I save it in GVIM, CyberDuck uploads the file back to the remote host.
I'm sure that this functionality is not unique to CyberDuck, and is probably present in most nicer file transfer utilities.
This is probably a simple problem and I'm feeling exceptionally dumb because I can't find a any kind of documentation.
I've just installed TeamCity 5 and I want to get files from my Mercurial hosting and there is two fields I just can't figure out.
HG Command path. What should I put here? The path to a file containing what? Can I get an example of that file somewhere?
The host is using Mercurial over SSH where do I define my private key?
Pull changes from? Should I put the address I'm cloning from i.e. ssh://username#myhost.something/project
I figured this out for my TeamCity 5 server last week.
HG Command path: HG
Pull changes from: https://bitbucket.org/.../.../
Don't put the username# in the URL. This is specificed as in the Username/Password fields. If you include the username in the URL it'll fail as there is a bug in the configuration tool. You'll also see a screenshot of the configuration attached to the thread:
http://www.jetbrains.net/devnet/message/5254640#5254640
I'd suggest getting things working with HTTPS and then moving to SSH if possible. This breaks things down into two easier to solve configuration problems. I used the following tutorial to get SSH going on my Windows client machine.
http://www.codza.com/mercurial-with-ssh-setup-on-windows
I've not set this up on my TeamCity server yet. However I did get TeamCity to pick up my Mercurial.ini settings by putting the ini file in \Documents and Settings\TeamCity, which is the account the service runs under.
I've not used team city, but I think hg command path is probably the full path to your local mercurial executable. For me (on linux) that's:
$ type hg
hg is /usr/bin/hg
On windows it's where the 'hg' executable in your system path was placed by whichever (of the many) windows installers for mercurial you used.
Pull changes from sounds like the URL to the repo, so:
ssh://username#myhost.something/project
or
ssh://username#myhost.something//project # note the _two_ double slashes
if you're using absolute paths on the server side.
Your private key location/specification depends on what you're using for ssh and whether or not you're running ssh-agent, but here's a links that explicitly points from within mercurial.ini, which seems sound:
http://dev.openttdcoop.org/projects/home/wiki/Configuring_TortoiseHg_(Windows)#Pointing-to-you-Private-key