Pkg: private repository usage and keys

Hm… I know that Windows has some weird git installation, so it’s possible that libgit and git are linked somehow, I’m not sure.

https://help.github.com/articles/caching-your-github-password-in-git/

3 Likes

I’m not sure this will really work as I’m trying to build in a docker, but thanks I’m sure it’ll be helpful for something at some point.

I think my real problem is that I’m trying to do a completely automated docker build, so even though I can use the credential helper during normal circumstances I’m not sure I can us it during the build process.

I think the best of bad options is going to be simply including everything that’s needed in the docker build directly. We are upgrading out git, at that point I’ll probably just tell IT that they have to fix the pull issues because it’s getting in the way of me doing my job.

Possibly related and some debugging hints: https://github.com/JuliaLang/Pkg.jl/issues/1516#issuecomment-560794389

Had this same issue, but on macOS Catalina. I needed to add my identity with ssh-add. From bash enter:

eval $(ssh-agent)
ssh-add

Then restart Julia. After this I was able to clone no problem!

3 Likes

I can confirm, I was having the same issue as @ExpandingMan , but @euthoff’s solution works for me on Julia v1.6.0-beta1. Can someone explain what’s going on? This definitely seems like a Pkg bug - I’ve never had to do anything like this with any other package manager.

Hard to say what exactly is your problem but I’ve documented the best practice I know for ssh keys at LocalRegistry.jl/ssh_keys.md at master · GunnarFarneback/LocalRegistry.jl · GitHub.

Thanks for this @GunnarFarneback. As you point out, apparently using the PEM SSH key format works, but not the default OPENSSH format (which I was using) because (quoting you)

LibGit2 gets its ssh functionality from libssh2 , which indeed is less capable of taking the ~/.ssh configurations into account than the ssh command line interface used by the git command line interface.

But it seems like @StefanKarpinski is working on improving this.

Apparently the above solution involving ssh-agent somehow makes incompatible keys available to libssh2 via an intermediary.

Just thought that summarizing the situation might be helpful for the next confused googler.

In general not using ssh-agent is a world of pain.
And that is sad.

1 Like

For what it’s worth I’ve never used ssh-agent and plain keys have worked fine at work for a long time now. (Also we’re running a package server for our internal packages these days, so the need to use ssh for packages is marginal.)

2 Likes