SFTP Key Exchange Error

[cmaves]

I'm excited to see SFTP added as a feature to FreeFileSync, however when using it with my Arch Linux server I get the following error when attempting to connect:
>Failed to connect to SFTP server "192.168.1.112".
>Error Code LIBSSH2_ERROR_KEX_FAILURE: Unable to exchange encryption keys (libssh2_session_handshake)

I can connect to this server using ssh and sftp with PuTTy and WinSCP. This problem with FFS occurs on installations of FFS on different computers. I can also use FFS to my phone with SFTP, so the problem has to be something specific between my Arch server and FFS. I was wondering if I could get some help solving this problem?

[Zenju]

Are you able to reproduce the error with the current beta?
[404, Invalid URL: https://freefilesync.org/FreeFileSync_7.3_beta_Windows_Setup.exe]

[cmaves]

Yes, it is. I also tried generating new keys with different encryption algorithms (rsa-1024, rsa-4096, dsa-2048), but the problem persisted.

[Zenju]

Are you somehow able to provide me with steps to reproduce the error on my end?

[cmaves]

The FFS client is easy to replicate. You can do this by installing it and using the default setting to attempt to connect. I attached the connection setting in a screenshot.
The server is more difficult to replicate. The server uses OpenSSH 6.8. I attach the configuration file used on the server, but I'm not sure it will be of any help.
The only way to completely replicate the issue would be to try to use FFS to connect to an Arch Linux distro that uses default OpenSSH settings.
The only time that I've gotten FFS to successfully connect to a server was when it was connecting to my phone, that uses a different implementation of SSH. So it could be an issue with libSSH2 and OpenSSH. However, if the problem truly is specific to OpenSSH, then the problem would likely be more widespread because of how common OpenSSH is.

[cmaves]

I did manage to get the SFTP to work, but I had to switch my Arch Linux server to Dropbear (v. 2015.67) implementation of the SSH.

This fix will work for me, but is still a pretty big issue if it affects all instances of OpenSSH. I'll run and OpenSSH server from a different linux distro to see if the problem is specific to my server or OpenSSH.

[Zenju]

Looks more like a libssh2 bug/limitation rather than a FFS integration issue. The best test would be to use another sftp tool that also uses libssh2 and see if this works. (if yes, then FFS should be fixable, too)

[metter]

Having the very same problem. But I am not nearly tech savy enough to help myself here.

While loging into my Synology SFTP Server, I get this via FFS:

Failed to connect to SFTP server "etter.diskstation.me".
Error Code LIBSSH2_ERROR_KEX_FAILURE: Unable to exchange encryption keys (libssh2_session_handshake)

[nusi]

Same problem here. Synology SFTP Server - LIBSSH2_ERROR_KEX_FAILURE.
Other popular software works stable.

[theking971]

I got the same error in combination with my NAS
Synology 215j DSM 5.2
FFS v7.4
LIBSSH2_ERROR_KEX_FAILURE: Unable to exchange encryption keys (libssh2_session_handshake)
If Zenju need a account for testing with my NAS, pls e-mail me.

[Zenju]

I got the same error in combination with my NAS
Synology 215j DSM 5.2
FFS v7.4
LIBSSH2_ERROR_KEX_FAILURE: Unable to exchange encryption keys (libssh2_session_handshake)
If Zenju need a account for testing with my NAS, pls e-mail me.

The problem is, the Synology NAS from your test case advertises support for the following ciphers:

* aes256-ctr
* aes192-ctr
* aes128-ctr
* aes128-gcm@openssh.com
* aes256-gcm@openssh.com
* chacha20-poly1305@openssh.com

However, FreeFileSync based on libssh2 using the WinCNG backend supports these ciphers:

* rijndael-cbc@lysator.liu.se
* aes256-cbc
* aes192-cbc
* aes128-cbc
* arcfour128
* arcfour
* 3des-cbc

The intersection of these two sets is empty. Ideally, FFS would just add support for one of the `aes*-ctr` ciphers, but that's probably not going to be simple and is a job for the libssh2 guys. Alternatively, maybe the Synology can be set up to use one of the ciphers that FFS currently supports?

[Zenju]

Just made a first test using OpenSSL instead of WinCNG as a libssh2 backend: OpenSSL supports the same ciphers like WinCNG and additionally the following ones:

* aes256-ctr
* aes192-ctr
* aes128-ctr
* cast128-cbc
* blowfish-cbc

[theking971]

It will be great if u can get it working !
The Synology NAS dont have a easy option to change it.
Only true Terminal/Telnet/SSH but that is a bit to complex for me and probably the changes will be undone after a update from Synology.

[Zenju]

The connection issue is basically solved by using the OpenSSL backend:
[404, Invalid URL: http://www.mediafire.com/download/55s10a7jo1js1j8/FreeFileSync_7.5_beta_Windows_Setup.exe]

The next problem is that the Synology SFTP server disconnects after each file upload: libssh2 is not smart enough to handle this and hangs. In order to have at least some reasonable behavior I've added a 10-seconds time out, so that the operation fails with LIBSSH2_ERROR_TIMEOUT instead.

[theking971]

I am getting a error missing MSVCP140D.dll when starting the new version.with a WIndows 7 pc, With my Windows 10, ucrtbased.dll is missing.

Probably for debug purposes?

[Zenju]

I am getting a error missing MSVCP140D.dll when starting the new version.with a WIndows 7 pc, With my Windows 10, ucrtbased.dll is missing.

Probably for debug purposes?

Thanks, fixed the link above.

[theking971]

No errors anymore with the last version and indeed FFS freezes after uploading the first or one file.

[Zenju]

I've analyzed the transport stream between libssh2 and the Synology server, but it looks to be fine according to the SFTP spec version 3, down to the bit.
But then for no apparent reason, the server responds with SSH_MSG_CHANNEL_EOF, SSH_MSG_CHANNEL_REQUEST(exit-signal), SSH_MSG_CHANNEL_CLOSE after a (perfectly valid) request to close the file handle was sent.
Empirically I found that this problem seems to be connected with setting file modification time by handle: Setting the modification time itself succeeds (SSH_FXP_STATUS, status code 0), but the next SFTP command will lead to the server disconnect above, no matter if it is a handle close or a second setting by modification time. (However retrieval of file attributes by handle will not fail, it seems only the next writing SFTP operation causes the disconnect).
From all these symptoms it looks like things go wrong on the Synology server, as a consequence of the modification time change by handle.
I made a different test setting the modification time by path and the disconnect problem does not appear! I've seen quite a number of Linux distributions having problems with setting modification time by handle and FFS therefore sets it by path for maximum compatibility. Therefore I'll do the same for the SFTP access and see if this suffices as a work around.

Let me know if you find any remaining issues with this version:
[404, Invalid URL: http://www.mediafire.com/download/9dwduankhy4fw17/FreeFileSync_7.5_beta_Windows_Setup.exe]

[theking971]

I cant find anything to whine about anymore, everyting works perfect now !

[Zenju]

I cant find anything to whine about anymore, everyting works perfect now !

Excellent! :)

[Plerry]

I cant find anything to whine about anymore, everyting works perfect now !

> I cant find anything to whine about anymore ...

It almost sounds like a disappointment ;-)