I see the connect method connects much faster in R6.9 (compared to 2012).
It's most likely using elliptic curve Diffie-Hellman, which is substantially faster than the classic modular Diffie-Hellman and was not supported in the old version of Rebex SFTP.
I'm creating new instances of the new sftp client, so there shouldn't be any "leak" between them, however it seems there is some.
There is a substantial leak and it's caused by your code. By failing to dispose instances of Sftp object, you are leaving them orphaned until .NET's garbage collector identifies and disposes them. However, each of these Sftp objects represents an active SSH session (connected, negotiated, but not yet authenticated). And until the GC disposes these, the underlying SSH session remain active.
Additionally, the operation of the garbage collector is by its nature somewhat unpredictable, which means your code might produce quite different results each run.
The following code demonstrates what might actually be going on, and it does it in a way that does not rely on unpredictable garbage collector behavior - it simply keeps successfully connected Sftp instances in a list:
var list = new List<Sftp>();
for (int i = 0; i < 1000; i++)
{
Sftp sftp = new Sftp();
try
{
sftp.Connect("193.19.176.97", 22);
Console.WriteLine(true);
success++;
list.Add(sftp); // ensure the object stays alive
//sftp.Disconnect();
//sftp.Dispose();
}
catch
{
Console.WriteLine(false);
sftp.Disconnect();
sftp.Dispose();
}
System.Threading.Thread.Sleep(100);
}
When running this against an OpenSSH server at 193.19.176.97, I get results quite similar to yours, with first failure occurring at around 13th connection attempt.
And these are the final results after 1000 runs:
Total Time: 138141
Success: 122/1000
This particular OpenSSH server is using the default values of MaxStartups, which specifies the maximum number of concurrent unauthenticated connections and also introduces some randomness (see https://linux.die.net/man/5/sshd_config for details), so the results seem to be entirely consistent with the server-side configuration.
On the other hand, if I connect to 195.144.107.198 instead (with no DDoS protection), I get 100% success:
Total Time: 125610
Success: 1000/1000
Furthermore, when I reconfigure the MaxStartups at 193.19.176.97 to allow 100 concurrent unauthenticated connections, I do actually get 100 successful connections (using the same client code) before the first failure.
Based on these experiments, I would say that server-side DDoS protection is indeed the cause of those "The connection was closed by the server. Make sure you are connecting to an SSH or SFTP server" errors.