Terminal error: "Negotiation failed. Server signature is not valid."

Question

Hello,

A few of our clients have been having issues using a recent version of Rebex (2017R6, released october 25th). When they connect to some of their SSH machines, they receive one of the two following errors:
"Negotiation failed. Server signature is not valid."
"Negotiation failed. The connection was closed by the server."

Is this issue something we can work around in 2017R6 by changing a setting? If you need more information or an access we could ask our clients if they can provide it, since we haven't been able to reproduce the issue with our setup.

Regards.

Answer 1

Please try to specify RSA as host key algorithm using Sftp object's Settings property before connecting to the server:

sftp.Settings.SshParameters.PreferredHostKeyAlgorithm = SshHostKeyAlgorithm.RSA;

If this doesn't solve the issue, please create a communication log and either post it here or mail it to support@rebex.net for analysis.

Comments

Testing in our environment, this didn't seem to have any change on the terminal's behavior. Changing the setting for HostKeyAlgorithms to something the server did or didn't support also didn't change anything, the connection was always successful for us.
I'll still ask your clients to change their host key settings and see if it helps, as well as enabling the communication logs.

---

I hope that the communication log showing the error in the context in which it occurred would shed some light onto this issue. Unfortunately, signature validation errors are very hard to analyze without the ability to reproduce them, but we will try.

---

I sent the logs to support@rebex.net, I hope they will help diagnose the issue.

---

Thanks for the log! This seems to be a rather old SSH server that supports RSA and DSA host key algorithms. The client preferred DSA and attempted to start SSH key exchange, which failed. Would it be possible to give this a try with RSA by setting "sftp.Settings.SshParameters.PreferredHostKeyAlgorithm = SshHostKeyAlgorithm.RSA"? If that fails as well, please send an updated log.

Some background information: Rebex SFTP prefers DSA for historical reasons, but this choice is getting increasingly problematic because almost all other SFTP/SSH clients prefer RSA or ECDSA and servers with misconfigured DSA keys are quite common. We plan to switch to using RSA by default in 2018 R1 release, but we have been postponing this because it is a breaking change.

---

Thanks for the quick reply Lukas. Our clients are currently using SSH connection as opposed to SFTP but I assume it's basically the same reasoning. We'll add the option to change the preferred algorithm and tell them to try out RSA.

---

Sorry for the confusion - SFTP runs over SSH as well and until the SSH session has been established and authenticated, the server doesn't even know whether the client is going to ask for an SFTP subsystem, for a shell, or another SSH feature.

---

So after looking further into it and with a bit of testing from our clients, they've identified that the issue is with the DiffieHellmanGroupExchangeSHA1 key exchange algorithm. Disabling it fixed their issue.

Did anything change in the past regarding this? I know SHA1 is not considered secure anymore, is it possible the server refused the connection since the Rebex component still allowed it?

---

DiffieHellmanGroupExchangeSHA1 key exchange could be a problem because there are two variants - a standard variant (where client specifies minimum, maximum and desired DH key size) and a legacy variant (where the client only specifies the desired DH key size). Modern servers support the standard variant, and some of them support the legacy variant, but some legacy servers only support the legacy variant. We try to guess the variant used according to multiple criteria, but this could never be entirely reliable.

Looking into the log again, I can confirm that DiffieHellmanGroupExchangeSHA1 was actually attempted. However, I now noticed that the client actually asked for a group exchange with a 512-bit key. This is definitely not secure, and it seems to have been set by a custom code because the default value here is 1024.
It's quite possible the server rejected the key exchange attempt because it rightly considered 512 bits to be too low.
Please make sure you are NOT doing something like this in your code:
    sftp.Settings.SshParameters.MinimumDiffieHellmanKeySize = 512

The log also shows that the server only supports two key exchange methods that are both based on SHA-1 ("diffie-hellman-group-exchange-sha1" and "diffie-hellman-group14-sha1"), which means that SHA-1 was almost certainly not the cause of refused connection attempts.