Help! Pkg.add from company's Bitbucket repository fails due to SSH authentication

I am not sure if this is a bug or I’m doing something wrong…

We have a Julia package hosted on our company’s private Bitbucket server. Since I had already created SSH keys at my Git for Windows client (Git Bash), and I had provided the public key to the Bitbucket server, I was able to clone / push / pull using my Git Bash or any GUI (Atom, Sublime Merge) without any problem.

However, when I tried to add the package in my Julia pacakge manager, this error happened:


(v1.3) pkg> add
   Cloning git-repo ``
Private key location for '' [C:\Users\zpan\.ssh\id_rsa]:
Private key location for '' [C:\Users\zpan\.ssh\id_rsa]:
ERROR: failed to clone from, error: GitError(Code:ERROR, Class:SSH, Failed to authenticate SSH session: Unable to send userauth-publickey request)

I double-checked that the private key location is correct, and the associated public key had been submitted to the Bitbucket server. If not, my other git operations would have failed.

And it’s not because the location cannot be found - the error message would be different if it had been the case.

Unfortunately SSH authentication is the only authentication method our Bitbucket server is set up to support. I cannot use https or any other protocol.

Anybody had similar problem? Did I miss something, or is it a bug?

Unfortunately working with private repositories on Windows seems to be a long standing issue. You’re far from the only one to have experienced this. I could be wrong but as far as I know it hasn’t been resolved. See the following thread for more info:

Seems like the standard workaround is to use https. That is what my company has done to accommodate Windows users. If https isn’t an option then I’m not sure what the best path forward is. There might be a way to get ssh to work on Windows.

@Pbellive Thank you for pointing me to the thread! After trying various combinations suggested by the replies and having a little “aha” moment of my own, I found the following workaround for Windows 10 with Julia 1.3.1:

(1) Regenerate the SSH key using the “-m PEM” option. In my case, the command line is:
ssh-keygen -t rsa -m PEM -C

Update the public key submitted to the private git server with the new key. Confirm that “git pull” can work.

(2) Create two system environmental variables:

SSH_KEY_PATH = C:/Users/zpan/.ssh/id_rsa
SSH_PUB_KEY_PATH = C:/Users/zpan/.ssh/

Alternatively, these also work:

SSH_KEY_PATH = C:\\Users\\zpan\\.ssh\\id_rsa
SSH_PUB_KEY_PATH = C:\\Users/zpan\\.ssh\\

Note the double backslash \\.

With these all set up, one can start a Julia session and add the package. There will be no prompt for the private key location and it would just work:

(v1.3) pkg> add ssh://
  Updating registry at `C:\Users\zpan\.julia\registries\General`
  Updating git-repo ``
  Updating git-repo `ssh://`
  Updating git-repo `ssh://`
 Resolving package versions...
  Updating `C:\Users\zpan\.julia\environments\v1.3\Project.toml`
  [045fb6ed] + mypackage v0.1.0 #master (ssh://
  Updating `C:\Users\zpan\.julia\environments\v1.3\Manifest.toml`
  [045fb6ed] + mypackage v0.1.0 #master (ssh://

What didn’t work for me:

  1. Typing in the path or accepting default when Pkg.add prompts for the private key location. I tried every format to no avail.
  2. Using single backslash \ (e.g. C:\Users\zpan\.ssh\id_rsa), or using the drive letter without : (e.g. /C/Users/zpan/.ssh/id_rsa) in the environmental variables.

I will post link to this Windows workaround to the relevant threads, too.


I’m obviously typing too slowly as this was resolved before I finished writing. I’ll post it anyway since it may be of value to future readers who get into similar problems and are desperate enough to try difficult approaches to find a solution.

To begin with the repeated question for “Private key location” doesn’t necessarily mean that it fails to find the key but that something, anything, goes wrong in the authentication process. Unfortunately the error messages don’t provide much information at all to track it down.

The reason why Pkg can fail when everything is set up and working with commandline git is that Pkg uses the libgit2 library, which in turn depends on the libssh2 library, which isn’t nearly as good as the ordinary ssh client in negotiating with the server side or understanding configuration options.

In order to have a chance to diagnose the problem you need to get some logs from the attempts to communicate with the server.

On the server side this can be done if you have a helpful bitbucket admin who can enable sshd logs. If this is not possible you can try to get Pkg to connect to another computer which you have control over and can enable logging on (just use a fake URL, it doesn’t matter if there’s no git repository to talk to as the problem is with the authentication). But first verify that you can actually replicate the problem that way.
Some of the comments in may be helpful if going this route.

On the client side you would have to patch the libssh2 dll to enable logging. In you can find a detailed instruction how to do that on Linux. The same principle applies on Windows although the details differ. This is doable if you have a compiler and some skills with building C or C++ packages.


Thank you! Using the PEM format for the key solves/works around the issue.

Which by the way persists on Julia 1.4.2.

Using the PEM format will be required until libssh2 implements support for other formats or Julia replaces libgit2/libssh2 with command line git for Pkg operations. This is nothing new, what has changed is that OpenSSH switched default output format for ssh-keygen in version 7.8. See for some more details.