SFTP Error: Negotiation failed. Unexpected EC key blob data.

0 votes
asked Apr 14 by stefan.kale (120 points)

Hi, I tried to establish a connection to an SFTP-server, and I got the following error. Can you help?
Thanks, Stefan

(I replaced the IP with 111.111.111.11)

2020-04-14 09:03:54.830 Opening log file.
2020-04-14 09:03:54.863 INFO FileLogWriter(1)[1] Info: Assembly: Rebex.Common 2020 R1.1 for .NET 3.5 SP1
2020-04-14 09:03:54.870 INFO FileLogWriter(1)[1] Info: Platform: Windows 6.2.9200 64-bit; CLR: 2.0.50727.8689
2020-04-14 09:03:54.871 DEBUG FileLogWriter(1)[1] Info: Culture: de; Windows-1252
2020-04-14 09:03:59.679 INFO Sftp(1)[1] Info: Connecting to 111.111.111.11:22 using Sftp.
2020-04-14 09:03:59.680 INFO Sftp(1)[1] Info: Assembly: Rebex.Sftp 2020 R1.1 for .NET 3.5 SP1 (Trial)
2020-04-14 09:03:59.680 INFO Sftp(1)[1] Info: Platform: Windows 6.2.9200 64-bit; CLR: 2.0.50727.8689
2020-04-14 09:03:59.680 DEBUG Sftp(1)[1] Info: Culture: de; Windows-1252
2020-04-14 09:03:59.699 DEBUG Sftp(1)[1] Proxy: Connecting to 111.111.111.11:22 (no proxy).
2020-04-14 09:03:59.741 DEBUG Sftp(1)[1] Proxy: Connection established.
2020-04-14 09:03:59.765 DEBUG Sftp(1)[1] SSH: Server is 'SSH-2.0-7.36 FlowSsh: Bitvise SSH Server (WinSSHD) 7.39'.
2020-04-14 09:03:59.780 INFO Sftp(1)[1] SSH: Negotiation started.
2020-04-14 09:04:00.049 DEBUG Sftp(1)[1] SSH: Negotiating key.
2020-04-14 09:04:00.065 ERROR Sftp(1)[1] SSH: Negotiation failed. Unexpected EC key blob data.
2020-04-14 09:04:00.085 ERROR Sftp(1)[1] Info: Rebex.Net.SshException: Negotiation failed. ---> System.Security.Cryptography.CryptographicException: Unexpected EC key blob data.
bei ndba.hnij(Int32 frv, Func`1 frw)
bei ncyc.jivu(Byte[] emi, Boolean emj)
bei ncwg.yynp(Byte[] iec)
bei ncvw.GetPublicKey()
bei ncwb.ncva.yhca()
bei Rebex.Security.Cryptography.AsymmetricKeyAlgorithm.jgbl(AsymmetricKeyAlgorithmId brb, String brc, Int32 brd)
bei xutd.vxac(SshSession fck, Byte[] fcl, Byte[] fcm, Byte[] fcn, Byte[] fco, xusq& fcp, Byte[]& fcq, SshPublicKey& fcr)
bei Rebex.Net.SshSession.gnhw(Byte[] aoh)
--- Ende der internen Ausnahmestapelüberwachung ---
bei Rebex.Net.SshSession.gnhw(Byte[] aoh)
bei Rebex.Net.SshSession.Negotiate()
bei Rebex.Net.Sftp.vpdl.belk(wsrf wl, Boolean wm)
bei Rebex.Net.Sftp.ajci(String lu, Int32 lv, SshParameters lw, wsrf lx)

Applies to: Rebex SFTP

1 Answer

0 votes
answered Apr 14 by Lukas Pokorny (108,330 points)

Hi, this looks like some incompatibility in ours and Bitvise's implementation of X25519 key exchange packet structures - the error occurred because instead of reading a sequence of zeros at the end of an X25519 public key structure, something else (or no data at all) was encountered.

We will need to look into this more thoroughly, but you can try this hotfix that relaxes the error checking a bit. Please let us know whether this helps or whether it just leads to key exchange error (which would indicate the problem is more complicated that just missing zero bytes).

commented Apr 15 by stefan.kale (120 points)
I tried the hotfix and got a disconnected by the server.
Here's the log:

2020-04-15 08:49:34.425 Opening log file.
2020-04-15 08:49:34.471 INFO FileLogWriter(1)[1] Info: Assembly: Rebex.Common (Hotfix Build 7410) for .NET 3.5 SP1
2020-04-15 08:49:34.487 INFO FileLogWriter(1)[1] Info: Platform: Windows 6.2.9200 64-bit; CLR: 2.0.50727.8689
2020-04-15 08:49:34.487 DEBUG FileLogWriter(1)[1] Info: Culture: de; Windows-1252
2020-04-15 08:49:36.248 INFO Sftp(1)[1] Info: Connecting to --.--.--:22 using Sftp.
2020-04-15 08:49:36.248 INFO Sftp(1)[1] Info: Assembly: Rebex.Sftp (Hotfix Build 7410) for .NET 3.5 SP1 (Trial)
2020-04-15 08:49:36.248 INFO Sftp(1)[1] Info: Platform: Windows 6.2.9200 64-bit; CLR: 2.0.50727.8689
2020-04-15 08:49:36.248 DEBUG Sftp(1)[1] Info: Culture: de; Windows-1252
2020-04-15 08:49:36.264 DEBUG Sftp(1)[1] Proxy: Resolving '--.--.--'.
2020-04-15 08:49:36.310 DEBUG Sftp(1)[1] Proxy: Connecting to 111.111.111.111:22 (no proxy).
2020-04-15 08:49:36.342 DEBUG Sftp(1)[1] Proxy: Connection established.
2020-04-15 08:49:36.389 DEBUG Sftp(1)[1] SSH: Server is 'SSH-2.0-8.37 FlowSsh: Bitvise SSH Server (WinSSHD) 8.37'.
2020-04-15 08:49:36.404 INFO Sftp(1)[1] SSH: Negotiation started.
2020-04-15 08:49:36.654 DEBUG Sftp(1)[1] SSH: Negotiating key.
2020-04-15 08:49:36.701 INFO Sftp(1)[4] SSH: Disconnected by the server ('').
2020-04-15 08:49:36.717 ERROR Sftp(1)[1] SSH: Negotiation failed. Disconnected by the server ('').
2020-04-15 08:49:36.905 ERROR Sftp(1)[1] Info: Rebex.Net.SshException: Disconnected by the server ('').
   bei Rebex.Net.SshSession.blhp[dg,dh](gxyv`2 ans, Int32 ant, gxyw anu, dh anv, dg anw, dg anx)
   bei Rebex.Net.SshSession.blho[dg,dh](gxyv`2 anq, dh anr)
   bei Rebex.Net.SshSession.blhw(gmmg aog)
   bei gmmm.kqfk(SshSession fck, Byte[] fcl, Byte[] fcm, Byte[] fcn, Byte[] fco, gmlz& fcp, Byte[]& fcq, SshPublicKey& fcr)
   bei Rebex.Net.SshSession.blhy(Byte[] aoh)
   bei Rebex.Net.SshSession.Negotiate()
   bei Rebex.Net.Sftp.mcix.tmlm(xboz wl, Boolean wm)
   bei Rebex.Net.Sftp.hnpo(String lu, Int32 lv, SshParameters lw, xboz lx)
commented Apr 15 by Lukas Pokorny (108,330 points)
Thanks for giving this a try and reporting back. We will need to look into this mor thoroughly. In the meantime, please try disabling X25519 key exchange support when connecting to Bitvise servers:

sftp.Settings.SshParameters.KeyExchangeAlgorithms = SshKeyExchangeAlgorithm.Any & ~SshKeyExchangeAlgorithm.Curve25519;
commented Apr 20 by Lukas Pokorny (108,330 points)
We tried reproducing this issue using Rebex SFTP 2020 R1.1 on Windows 10 and various versions of Bitvise WinSSHD server (also on Windows 10), but X25519 key exchange with all of them appears to be working fine. These are the version we tested: 8.41, 7.45, 7.42, 7.31. Are you aware of anything that might have be different in your scenario?

Could you try connecting using OpenSSH client (available on almost any Linux or on Windows Ubuntu subsystem) with the following command?
"ssh -vvv -o KexAlgorithms=curve25519-sha256 111.111.111.111"

We are also unsure which version you are connecting to - your original log indicated 7.36 or 7.39, but the subsequent log has 8.37. Has the server just been upgraded few days ago?
...