Libssh2 on Windows

GunnarFarneback · August 28, 2018, 3:36pm

Short summary: libssh2.dll in the official Windows binaries is out of date with respect to available ciphers and needs upgrade in order for Pkg to keep working with packages on private git servers using ssh protocol, if it hasn’t already stopped working.

Longer story:
When trying to add packages from private git servers (such as gitlab or bitbucket) using ssh URL:s, Pkg needs to talk to the ssh server on the host, which it does via LibGit2 and in turn libssh2. In order for this communication to be successful, the client and server needs to agree on a number of things, including what kind of cipher to use. Since old ciphers become less safe over time and new ciphers are invented to replace them, ssh client and servers need to be sufficiently in sync.

This is becoming problematic with the official Julia binaries on Windows. The ssh connection initiated by Pkg.add() offers the following ciphers: aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-cbc,aes128-cbc,arcfour128,arcfour,3des-cbc

None of those is considered safe enough to be accepted by a default configured Ubuntu 16.04 openssh server and at my work they are still accepted by the gitlab server (which is rather behind on updates) but not by the bitbucket server.

On Linux the situation is better. With a Julia 1.0 built from source, the list of ciphers is: aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-cbc,aes128-cbc,blowfish-cbc,arcfour128,arcfour,3des-cbc

The first 3 of those overlap what my openssh server accepts (chacha20-poly1305@openssh.com ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com ,aes256-gcm@openssh.com) and are enough to talk to the bitbucket server.

Even though it may be possible to tweak the ssh configuration on private git servers that you have enough control over, it’s not always a viable option and this will only become worse over time, so the Windows libssh2 needs to become better.

As far as I can tell, the official Julia 1.0 Windows download ships with a libssh2.dll of version 1.7 whereas Linux built from source has version 1.8. I don’t know if this is enough to explain the difference in available ciphers or if it also depends on build options on Windows.

How is libssh2 built for the official Windows binaries today? What would it take to upgrade them enough to support the aesNNN-ctr ciphers?

simonbyrne · August 28, 2018, 5:49pm

Could you please open an issue: Issues · JuliaLang/julia · GitHub?

simonbyrne · August 28, 2018, 5:59pm

How are you checking the version of the one bundled with Julia?

GunnarFarneback · August 28, 2018, 6:17pm

Not very scientifically. Hovering the mouse over libssh2.dll in the explorer gave a four line popup, which included the string 1.7.0.0, which I took as an indication that it was a 1.7 libssh2.

simonbyrne · August 28, 2018, 6:26pm

I’m not 100% sure, but there is a chance that could be wrong, since it looks like they didn’t update the version string when tagging 1.8.0:

github.com

libssh2/libssh2/blob/libssh2-1.8.0/include/libssh2.h#L49


      
          
          
#ifndef LIBSSH2_H
          #define LIBSSH2_H 1
          
          
#define LIBSSH2_COPYRIGHT "2004-2016 The libssh2 project and its contributors."
          
          
/* We use underscore instead of dash when appending DEV in dev versions just
             to make the BANNER define (used by src/session.c) be a valid SSH
             banner. Release versions have no appended strings and may of course not
             have dashes either. */
          #define LIBSSH2_VERSION                             "1.7.0_DEV"
          
          
/* The numeric version number is also available "in parts" by using these
             defines: */
          #define LIBSSH2_VERSION_MAJOR                       1
          #define LIBSSH2_VERSION_MINOR                       7
          #define LIBSSH2_VERSION_PATCH                       0
          
          
/* This is the numeric version of the libssh2 version number, meant for easier
             parsing and comparions by programs. The LIBSSH2_VERSION_NUM define will
             always follow this syntax:

Either way, the cipher thing is still a problem, so it would be good to have in the issue tracker.

GunnarFarneback · August 28, 2018, 7:10pm

https://github.com/JuliaLang/julia/issues/28933

Thuener · April 12, 2019, 1:07am

This issue with Windows is very complicated and hard to diagnosticate. In my case, I only have the message error: GitError(Code:ERROR, Class:SSH, failed to start SSH session: Unable to exchange encryption keys)
I did everything right with the keys but couldn’t get julia to add a repository in Ubuntu 16.04(Gitlab server).

bomber8013 · July 3, 2019, 4:06am

Same here when trying on Windows. I can use ssh and git from command line just fine, in fact, for my private registry I switched my package registrator to using shell got commands instead of the Pkg git functions since I kept getting the ssh encryption key error too.

I ran into problems again, trying to switch my registry from https to ssh, just adding the registry using the ssh protocol causes Pkg to fail with the encryption key issue again.