2024.1.0 problem with Globalscape EFT and AES-GCM algorithms

[ibalmaci]

When I try to connect with Ssh.net 2024.1.0 to Globalscape Eft 8.2.1.30, get following error:

An established connection was aborted by the server. 
   at Renci.SshNet.Session.WaitOnHandle(WaitHandle waitHandle, TimeSpan timeout)
   at Renci.SshNet.Session.Connect()
   at Renci.SshNet.BaseClient.CreateAndConnectSession()
   at Renci.SshNet.BaseClient.Connect()

But, with 2024.0.0 version, there is no problem. I supposed there's a MAC algorithm problem.

[Rob-Hague]

Strange, there were no algorithms removed between 2024.0.0 and 2024.1.0. There were aes-gcm ciphers added, and also the strict-kex extension

I do see this kb but they don't provide any information about the algorithms that the server offers.

Could you see what algorithms the server is offering? You can do that with nmap:

nmap --script ssh2-enum-algos -p 22 example.com

Or you might be able to inspect these properties on the ConnectionInfo instance in the library (if they get set before the connection drops):

client.ConnectionInfo.CurrentKeyExchangeAlgorithm
client.ConnectionInfo.CurrentServerEncryption
client.ConnectionInfo.CurrentServerHmacAlgorithm
client.ConnectionInfo.CurrentHostKeyAlgorithm
client.ConnectionInfo.CurrentServerCompressionAlgorithm

You can also try this before connecting to rule out aes-gcm:

client.ConnectionInfo.Encryptions.Remove("[email protected]");
client.ConnectionInfo.Encryptions.Remove("[email protected]");

[ibalmaci]

And I also added following line before connection:

client.ConnectionInfo.CompressionAlgorithms.Remove("[email protected]");

And the connection was successfully established with 2024.1.0 version. But I'm not sure if this still counts as a bug.

Thank you

[Rob-Hague]

Glad you got it working. It sounds like a bug but hard to tell whose side it is on

For posterity, was it only the [email protected] that you had to remove or also the aes-gcm algorithms?

[cord-agencyroot]

I have this exact same issue. If I removed all the encryption methods besides the [email protected] and [email protected], then it worked fine.

Its almost like whatever code is used to determine the encryptions is not finding the correct one. This is from their knowledge base. They appear to prefer the gcm methods.

Is there a way to have it "prefer" a specific encryption method? Is that just the order in the list?

[Rob-Hague]

Interesting that they claim it is an issue with WinSCP/PuTTY. Seems to me that their server is not respecting the client algorithm priorities. cc @martinprikryl

Is there a way to have it "prefer" a specific encryption method? Is that just the order in the list?

It should be the order in the list that the client specifies. Currently SSH.NET is not entirely reliable in that regard because it uses Dictionary<> under the hood

[ravi-kamboj]

I'm facing same issue. My code was working fine till 15th Nov but not sure why I'm getting this error now. Can anyone please help me in this. I'm getting below error: Renci.SshNet.Common.SshConnectionException HResult=0x80131500 Message=An established connection was aborted by the server. Source=Renci.SshNet StackTrace: at Renci.SshNet.Session.WaitOnHandle(WaitHandle waitHandle, TimeSpan timeout) at Renci.SshNet.Session.WaitOnHandle(WaitHandle waitHandle) at Renci.SshNet.Session.Connect() at Renci.SshNet.BaseClient.CreateAndConnectSession() at Renci.SshNet.BaseClient.Connect()

I have tried with adding below 3 lines before establishing connection.

sftpClient.ConnectionInfo.Encryptions.Remove("[email protected]"); sftpClient.ConnectionInfo.Encryptions.Remove("[email protected]"); sftpClient.ConnectionInfo.CompressionAlgorithms.Remove("[email protected]");

[cord-agencyroot]

@ravi-kamboj try removing all the keys EXCEPT the aes-gcm ones. Something like :

var keys = sftpClient.ConnectionInfo.Encryptions.ToList() ?? [];

foreach (var encryption in sftpClient.ConnectionInfo.Encryptions.Where(pair => !pair.Key.Contains("gcm")))
{
  sftpClient.ConnectionInfo.Encryptions.Remove(encryption);
}

[cord-agencyroot]

Interesting that they claim it is an issue with WinSCP/PuTTY. Seems to me that their server is not respecting the client algorithm priorities. cc @martinprikryl

Is there a way to have it "prefer" a specific encryption method? Is that just the order in the list?

It should be the order in the list that the client specifies. Currently SSH.NET is not entirely reliable in that regard because it uses Dictionary<> under the hood

Yeah, that's kinda what I figured, no other SFTP host I've run into has this issue. For now, I just had to build a special exception when connecting to this host.