Rebex SSH Shell - Connection to SSH server failed with "No common encryption algorithm between client and server"

Question

Hello,

I am using Rebex.SshShell.dll version - 5.0.7620.0 to connect to SSH server from Web Application hosted on Windows IIS server.
I have enabled FIPS on this machine.

I am setting "rebexSsh.Settings.SshParameters" to set encryption algorithm ( tried setting all values of ENUM SshEncryptionAlgorithm ).But still on .connect() call it is failing with below error.

Exception: Type- Rebex.Net.SshException Message- Negotiation failed. The client and the server have no common encryption algorithm.

Disabling FIPS policy on windows server is not an option for me.

Please help.

Answer 1

In FIPS-only mode, only FIPS-validated cryptographic algorithms provided by Windows are used. The same applies when Rebex UseFipsAlgorithmsOnly option is set to true (this is the default value for Windows running in FIPS mode).

In your scenario, the server most likely refuses AES/CBC ciphers, does not support AES/GCM ciphers, and requires the client to use AES/CTR ciphers. However, Windows does not offer any FIPS-compliant AES/CTR implementation, so this cipher is not available in FIPS-only mode of Rebex components.

There are several possible solutions:

• Configure the server to allow AES/CBC ciphers, or upgrade to a server that supports AES/GCM ciphers.

• Configure the client app to allow AES/CTR ciphers by disable FIPS-only mode for Rebex SFTP:

``

Rebex.Security.Cryptography.CryptoHelper.UseFipsAlgorithmsOnly = false;

Comments

Thank you  Lukas Pokorny  for your reply.
But the strange thing here is -  if I use same rebex ssh library with winodws FIPS mode enabled in any WCF service to connect to SSH server it works perfectly fine.

why there is problem when I do the same from IIS web application? Does rebex library has permission issue because of different app domain?

---

App permissions in IIS might make a difference. OS version might make a difference as well, although mostly with old OS versions such as Windows Server 2003.

Anyway, to find out what's actually the difference, use Ssh object's LogWriter property to create a communication log - see https://www.rebex.net/kb/logging/ for details. If you create logs of Ssh.Connect at LogLevel.Verbose at each of those two applications, you will see a list of SSH ciphers supported by the client and server, making it possible to tell what's missing. Feel free to mail us the logs for analysis to support@rebex.net (comment out any sensitive information such as IP addresses, etc.).

---

Hello Lukas Pokorny,

I tried to collect Verbose logs from both Web Application and WCF service (under FIPS mode ON ) and by the logs I get why it was working via WCF service.

Under WCF Service -

CryptoHelper.UseFipsAlgorithmsOnly  has value "false"  and the logs are like -

2021-06-09 19:49:58.613 Opening log file.
2021-06-09 19:49:58.613 INFO FileLogWriter(1)[19] Info: Assembly: Rebex.Common 2020 R5 for .NET 4.6-4.8
2021-06-09 19:49:58.613 INFO FileLogWriter(1)[19] Info: Platform: Windows 6.2.9200 64-bit; CLR: 4.0.30319.42000
2021-06-09 19:49:58.613 DEBUG FileLogWriter(1)[19] Info: Culture: en; Windows-1252
2021-06-09 19:49:58.629 INFO Ssh(1)[19] Info: Connecting to XXXX:5022 using Ssh.
2021-06-09 19:49:58.645 INFO Ssh(1)[19] Info: Assembly: Rebex.SshShell 2020 R5 for .NET 4.6-4.8
2021-06-09 19:49:58.645 INFO Ssh(1)[19] Info: Platform: Windows 6.2.9200 64-bit; CLR: 4.0.30319.42000
2021-06-09 19:49:58.645 DEBUG Ssh(1)[19] Info: Culture: en; Windows-1252
2021-06-09 19:49:58.660 DEBUG Ssh(1)[19] Proxy: Connecting to XXXX :5022 (no proxy).
2021-06-09 19:49:58.660 DEBUG Ssh(1)[19] Proxy: Connection established.
2021-06-09 19:49:58.676 VERBOSE Ssh(1)[19] SSH: Sending data:
-- Later it connects to SSH server successfully as it does not use fips ------



Under WebApp-

CryptoHelper.UseFipsAlgorithmsOnly  has value "true"  and I can clearly see this in Verbose logs as well.

2021-06-09 22:05:32.833 Opening log file.
2021-06-09 22:05:32.833 INFO FileLogWriter(1)[28] Info: Assembly: Rebex.Common 2020 R5 for .NET 4.6-4.8
2021-06-09 22:05:32.833 INFO FileLogWriter(1)[28] Info: Platform: Windows 10.0.14393 32-bit (FIPS-only); CLR: 4.0.30319.42000
2021-06-09 22:05:32.833 DEBUG FileLogWriter(1)[28] Info: Culture: en; Windows-1252
2021-06-09 22:05:32.848 INFO Ssh(1)[28] Info: Connecting to XXXX:5022 using Ssh.
2021-06-09 22:05:32.848 INFO Ssh(1)[28] Info: Assembly: Rebex.SshShell 2020 R5 for .NET 4.6-4.8
2021-06-09 22:05:32.848 INFO Ssh(1)[28] Info: Platform: Windows 10.0.14393 32-bit (FIPS-only); CLR: 4.0.30319.42000
2021-06-09 22:05:32.848 DEBUG Ssh(1)[28] Info: Culture: en; Windows-1252
2021-06-09 22:05:32.864 DEBUG Ssh(1)[28] Proxy: Connecting to XXXX:5022 (no proxy).
2021-06-09 22:05:32.864 DEBUG Ssh(1)[28] Proxy: Connection established.
2021-06-09 22:05:32.880 VERBOSE Ssh(1)[28] SSH: Sending data:
---- Later it failed with no common encryption algorithm ----


Now the questions are  -
1.Why CryptoHelper.UseFipsAlgorithmsOnly is not set to true ( as it derives value from Windows FIPS mode which is ON ) in WCF service but in WebApp ?

2. As per this (https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2356.pdf ) PDF doc AES in CTR mode is FIPS compliant then why Rebex component is not allowing it under FIPS ?

Environment details  -  Win server 2016, .NET framework 4.8

 Thank you in advance for your help !

---

1) This looks like CryptoHelper.UseFipsAlgorithmOnly did not detect FIPS mode properly in WCF service's environment. It might be a bug - we will look into this! Can you please determine the value of .NET's CryptoConfig.AllowOnlyFipsAlgorithms property there as well? (https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.cryptoconfig.allowonlyfipsalgorithms)

2) When the system is in FIPS-only mode, we only use algorithms that are FIPS-validated and provided by Windows cryptographic APIs. We are aware of the document listing AES/CTR as supported by Windows Cryptographic Primitives Libraries, but as far as we know, no API for that feature has been published (see https://docs.microsoft.com/en-us/windows/win32/seccertenroll/cng-cryptographic-algorithm-providers). When such API becomes available, we will quickly add support for it. But until then, to be able to use AES/CTR on FIPS-only system, we would either have to implement a custom extension module and have it FIPS-validated, or use a third-party FIPS-validated module.

---

Thank you Lukas Pokorny for such exhaustive explanation.
 
.NET's CryptoConfig.AllowOnlyFipsAlgorithms property is setting as "true" for WCF service when FIPS is ON. So seems Rebex SSH might have bug around this.

By that time I tried enabling AES-CBC cipher on SSH server and it worked !!

Thank you for all your support and cooperation. I hope this bug will be fixed in next release of Rebex.

---

Thanks for the update! While looking into this issue, we discovered that our FIPS-detection routine is not working properly on .NET Framework 4.8 due to changes in the framework's behavior (https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/retargeting/4.7.2-4.8). We will fix this promptly and publish a new version within days. Sorry for the inconvenience, and thanks for bringing this issue to our attention!

---

This issue has been fixed in Rebex release R5.3: https://www.rebex.net/total-pack/history.aspx#R5.3