Rebex SFTP: Key exchange failed. Server signature is not valid.

0 votes
asked Nov 14, 2016 by mingchen (120 points)

Hi, we connect to an external SFTP server with Rebex. Today after the server was upgraded CrushFtp version 3 to version 7.7, we start to receive the following exceptions. Any idea what the error mean and how to fix? Thanks.

2016-11-14 11:46:26.081 DEBUG Sftp(1)[1] SSH: Validating signature.
2016-11-14 11:46:26.082 DEBUG Sftp(1)[1] SSH: Negotiation failed: Rebex.Net.SshException: Key exchange failed. Server signature is not valid. ---> Rebex.Net.SshException: Server signature is not valid.
   at Rebex.Net.OGB.L(Byte[] A, Byte[] B, Byte[] C, SshPublicKey& D)
   at Rebex.Net.PGB.D(SshSession A, Byte[] B, Byte[] C, Byte[] D, Byte[] I, Byte[]& J, Byte[]& L, SshPublicKey& M)
   at Rebex.Net.SshSession.BZ(Byte[] A)
   --- End of inner exception stack trace ---
   at Rebex.Net.SshSession.BZ(Byte[] A)
2016-11-14 11:46:26.082 ERROR Sftp(1)[1] SSH: Rebex.Net.SshException: Key exchange failed. Server signature is not valid. ---> Rebex.Net.SshException: Server signature is not valid.
   at Rebex.Net.OGB.L(Byte[] A, Byte[] B, Byte[] C, SshPublicKey& D)
   at Rebex.Net.PGB.D(SshSession A, Byte[] B, Byte[] C, Byte[] D, Byte[] I, Byte[]& J, Byte[]& L, SshPublicKey& M)
   at Rebex.Net.SshSession.BZ(Byte[] A)
   --- End of inner exception stack trace ---
   at Rebex.Net.SshSession.BZ(Byte[] A)
   at Rebex.Net.SshSession.AZ()
   at Rebex.Net.SshSession.Negotiate()
2016-11-14 11:46:26.082 ERROR Sftp(1)[1] Info: Rebex.Net.SshException: Key exchange failed. Server signature is not valid. ---> Rebex.Net.SshException: Server signature is not valid.
   at Rebex.Net.OGB.L(Byte[] A, Byte[] B, Byte[] C, SshPublicKey& D)
   at Rebex.Net.PGB.D(SshSession A, Byte[] B, Byte[] C, Byte[] D, Byte[] I, Byte[]& J, Byte[]& L, SshPublicKey& M)
   at Rebex.Net.SshSession.BZ(Byte[] A)
   --- End of inner exception stack trace ---
   at Rebex.Net.SshSession.BZ(Byte[] A)
   at Rebex.Net.SshSession.AZ()
   at Rebex.Net.SshSession.Negotiate()
   at Rebex.Net.Sftp.QNB.BZ(BNB A)
   at Rebex.Net.Sftp.XM(String A, Int32 B, SshParameters C, BNB D)
2016-11-14 11:46:26.164 ERROR Sftp(1)[1] Info: System.InvalidOperationException: Not connected to the server.
   at Rebex.Net.Sftp.FP(String A, String B, SshPrivateKey C, BNB D)
Applies to: Rebex SFTP

2 Answers

0 votes
answered Nov 15, 2016 by Lukas Pokorny (93,630 points)

My guess is that the new version of your SFTP server added support for an additional key exchange algorithm, but its implementation is not compatible with ours. Which version of Rebex SFTP do you use?

If this server (or any equivalent) is accessible from the internet, we could try reproducing this ourselves and hopefully fix at as well. In this case, let us know. We don't need any username or password because this error occurs before the authentication phase.

commented Nov 15, 2016 by mingchen (120 points)
Thanks Lukas,

Our version Rebex.Sftp is 3.0.5715.0. The server is accessible from ftp.fascet.com. However there may be IP based filter so you may not be able to access it.
commented Nov 15, 2016 by Lukas Pokorny (93,630 points)
You are right, it's not accepting connections from us on port 22. Could you please create a communication log of Rebex SFTP as described at http://www.rebex.net/kb/logging/ and either post it here or mail it to us for analysis?
commented Nov 15, 2016 by mingchen (120 points)
I emailed the log file to 'support@rebex.net'. Thanks.
commented Nov 15, 2016 by Lukas Pokorny (93,630 points)
Thanks for the log!

Could you please try connecting once again, this time preferring RSA instead of DSS server host key? To do this, add the following line to your code:

client.Settings.SshParameters.PreferredHostKeyAlgorithm = SshHostKeyAlgorithm.RSA;
(where 'client' is an instance of Sftp object).

In case this doesn't work either, please mail us a new log as well.
commented Nov 15, 2016 by mingchen (120 points)
Yep that seems to have worked. Thanks!
commented Nov 15, 2016 by Lukas Pokorny (93,630 points)
Thanks for letting us know! The question that remains now is whether the issue with DSS server host key exchange is in the client or the server. Unlike Rebex SFTP, most third-party SFTP/SSH clients prefer RSA by default, so a server bug might actually go unnoticed. We will try doing some tests to determine this, and we will also consider making RSA the default as well. Until then, there is nothing wrong with keeping the PreferredHostKeyAlgorithm setting.
0 votes
answered Sep 22, 2017 by Lukas Matyska (46,810 points)

Another client also uses the CrushFtp server and he is experiencing the same issue. In this case the server is accessible from the internet. We tried to connect to the server with the latest version of PuTTY (v0.70) using DSA and it also reported the exact same issue.

"Server's host key did not match the signature supplied"

We considered this to be a bug in the CrushFtp server.

The solution is to prefer other host key algorithm. It can be set easily like this:

client.Settings.SshParameters.PreferredHostKeyAlgorithm = SshHostKeyAlgorithm.RSA

Actually, DSA is preferred by default only for backward compatibility. It is suggested to use PreferredHostKeyAlgorithm = SshHostKeyAlgorithm.RSA always in new projects (which most third-party SFTP/SSH clients prefer by default).

commented Jan 23 by Lukas Pokorny (93,630 points)
zenny6377: Upgrading to at least Rebex SFTP 2016 R1 and using "PreferredHostKeyAlgorithm = SshHostKeyAlgorithm.RSA" should solve the issue. See http://forum.rebex.net/7746/experienced-issue-setting-preferred-algorithm-doesnt-help?show=7748#a7748 for more information.
commented Sep 10 by AptWar (100 points)
Thanks for this post it was helpful in pointing me in the right direction.  I thought I would post this additional information I found while diagnosing this in relation to CrushFTP.

Rebex SFTP Rebex.Sftp.dll 3.0.6821.0 (Trial) downloaded as of 08/09/18
CrushFTP 8.3.1 (Trial) to diagnose customer issue!  as of 08/09/18

We were getting this message returned

15:52:28.551 Debug SSH: Validating signature.
15:52:28.552 Error SSH: Negotiation failed. Server signature is not valid.
15:52:28.552 Error Info: Rebex.Net.SshException: Server signature is not valid.

When looking into this further I could see, as mentioned above this was indeed trying to use DSS,  SSH_MSG_KEX_DH_GEX_REPLY contained ssh-dss.

15:52:28.427 Verbose SSH: Received packet SSH_MSG_KEX_DH_GEX_REPLY (1166 bytes).
 0000 |21-00-00-03-39-00-00-00 07-73-73-68-2D-64-73-73| !...9....ssh-dss

The way that I resolved this without making any Rebex changes was to change the setting in CrushFTP
Preferences>IP/Servers>SFTP (on left)>SSH tab (on right)>Take the tick out of the Server Host Key (DSA) option.

I could then see that the SSH_MSG_KEX_DH_GEX_REPLY was then ssh-rsa

15:50:31.251 Verbose SSH: Received packet SSH_MSG_KEX_DH_GEX_REPLY (1332 bytes).
 0000 |21-00-00-02-17-00-00-00 07-73-73-68-2D-72-73-61| !........ssh-rsa
 0010 |00-00-00-03-01-00-01-00 00-02-01-00-8E-0F-E8-30| ...............0

and the connection worked fine.

** Can I confirm with you please that DSS is the default that Rebex will take if it is offered?  Has this been changed or do we have to apply the "client.Settings.SshParameters.PreferredHostKeyAlgorithm = SshHostKeyAlgorithm.RSA" as above? My understanding (just through reading I am not a developer!) is that DSS is generally turned off as a default now (OpenSSH 7 start of 2016) as it is seen as insecure and is generally now only available for backwards compatibility?  If so I think we should have to code that we want to use DSS rather than code that we need to use RSA? It may be a complete misunderstanding on my part as a newbie here!

Hope at least some of this is useful to someone! :-)

Thank you!

Rich
commented Sep 10 by Lukas Pokorny (93,630 points)
Thanks for your investigation!
You are right about DSS as well, and it's true that new code should no longer use it (unless there is a strong reason). In .NET Standard / .NET Core edition, we already use DSS by default, and the forthcoming .NET 4.6 edition (not yet released) prefers RSA as well. However, we are a bit hesitant to change the default in other editions because doing so might break lot of existing code that assumes that DSS is going to be used by default. However, it looks like we are approaching a point where switching the default to RSA is going to be lesser of two evils, and we'll probably make the switch in 2019 R1 release. Until then, please keep using "client.Settings.SshParameters.PreferredHostKeyAlgorithm = SshHostKeyAlgorithm.RSA". Sorry for inconvenience!
commented Sep 10 by AptWar (100 points)
Thanks for the update on the roadmap Lukas, useful stuff.  I'm not quite sure what the issue is between CrushFTP and Rebex is, looks like there is a potential bug in one or the other but looks like we now have two good workable solutions, thanks again Rich
commented Sep 11 by Lukas Pokorny (93,630 points)
We were actually able to reproduce the issue using PuTTY 0.70 as client and CryshFTP as server, which suggests that the bug is in CrushFTP's DSS implementation.
commented Sep 11 by AptWar (100 points)
This does look like the case as looking back through the other comments this happened after people upgraded their versions of CrushFTP but I can't see which version they upgraded from > to.  Thanks again Lukas, Rich
...