0 votes
by (150 points)


I have this version:
Rebex.Net.Sftp = v4.0.30319

And recently our partner is upgrading their SSH host keys from
1028bits to 2048bits.

Additionally they are only going to accept three ciphers:

  1. aes256-ctr
  2. aes192-ctr
  3. aes128-ctr

and three MAC:

  1. hmac-sha256
  2. hmac-sha2-256
  3. hmac-sha2-512

So without making any code changes I tried to connect to their UAT server to start testing and I get this error...the error in the subject line.

I have no idea what the ciphers nor MAC mean, but I read other post to see if I could figure it out.

Here's what I found:

  1. I cannot log because I do not have RebEx.Common.dll anywhere on my system.
  2. I cannot change any settings because Settings is not a class in SFTP in my version.
  3. If I change the hostname back to production (because they have not roll in this change yet) I can connect (sftp.connect(hostname)) just fine.

So, I need helps please.


1 Answer

0 votes
by (145k points)
selected by
Best answer


"v4.0.30319" not a version of Rebex SFTP - it's the version of .NET Framework it targets. However, if the assembly file name is Rebex.Net.Sftp.dll, this indicates that you use Rebex SFTP v2.0.4086 or earlier (we changed DLL names in the subsequent release).

That version is now more than 8 year and although it already had support for the three AES/CTR ciphers, it didn't support any of the SHA-2 HMAC ciphers. Those have only been supported since Rebex SFTP 2014 R1 (released 5 years ago). To learn more about these ciphers, check out theese cipher charts.

And to address your findings:

1) DLLs in Rebex SFTP v2.0.4086 and earlier were named differently and there was no Rebex.Common.dll. See this blogpost for details.

2) The old Sftp class lacked the Settings property. Instead, it had Options property and a Connect method overload that accepts an instance of SshParameters. These could be used to specify many of the settings that are now accessible via the Settings property.

3) The old version doesn't support any SHA-2 HMAC ciphers yet, so this behavior is as expected. To make it work, you would need to upgrade to a more recent version that supports contemporary SSH ciphers.