SshConnectionException after update to 2023.0.0 with private key file #1233
Comments
|
Could you please share the error details? |
|
I can share the stack trace here: at Renci.SshNet.Session.WaitOnHandle(WaitHandle waitHandle, TimeSpan timeout) Here is my test code: Please explain how to get more useful details if needed |
|
What type of key is it? RSA? If so, could you try the following before client.ConnectionInfo.HostKeyAlgorithms.Remove("rsa-sha2-512");
client.ConnectionInfo.HostKeyAlgorithms.Remove("rsa-sha2-256");If you are then able to connect, could you add the following after Console.WriteLine(client.ConnectionInfo.ServerVersion);and post the output here? |
|
Sorry misclicked... |
|
Thank you! The key starts with |
|
It would be helpful if you can share your server side logs. |
|
I don't have access to the server, but I'll try to get the logs I tried the client.ConnectionInfo.ServerVersion with the 2020.0.2 SSH.NET nuget (where the client.Connect() is working) and it is: |
|
The surefire way to narrow down what caused it is to run a git bisect. The steps would be: git clone https://github.com/sshnet/SSH.NET.git
cd SSH.NET/
dotnet build -f netstandard2.0 .\src\Renci.SshNet\Renci.SshNet.csproj
# Have your application reference src\Renci.SshNet\bin\Debug\netstandard2.0\Renci.SshNet.dll
# Test that your application runs (we are expecting to get the error here)
git bisect
git bisect good 2020.0.2
git bisect bad 2023.0.0
# git will then automatically checkout a commit between the two releases.
# Each time it does, run the same dotnet command
dotnet build -f netstandard2.0 .\src\Renci.SshNet\Renci.SshNet.csproj
# and then run your application and see if you get the error.
# If you do get the error, run
git bisect bad
# and if it connects OK, run
git bisect good
# If the "dotnet build" command fails on a particular commit, run
git bisect skip
After around 5 iterations, git should be able to tell you what commit caused the issue. If you could do that it would be most helpful, but I wouldn't blame you if you didn't - it's an arduous process. |
|
Hi! Thank you for the instructions! Did I miss anything? sorry if it's obvious, I'm stuck |
|
Sorry about that, I also get the error with a .NET Framework project and I don't know why. I managed to get it working with the following:
Then it should work (no idea why). You should only have to do that once. |
|
this is what git bisect said: 8732d3d is the first bad commit .../Common/RemoteSshdConfigExtensions.cs | 2 - |
|
Great, thanks for tracking it down. I will try to think about what could have caused it from that commit. |
|
thank you! |
|
Please could you try both of the following? I expect at least one of them to work. PrivateKeyFile key = new PrivateKeyFile(@"C:\repos\keys\encrypted_private.key", "passphrase");
var algs = (List<HostAlgorithm>)key.HostKeyAlgorithms;
// Keep ssh-rsa
algs.RemoveAt(0);
algs.RemoveAt(0);
SftpClient client = new SftpClient("host", 5022, "user", key);
// the restPrivateKeyFile key = new PrivateKeyFile(@"C:\repos\keys\encrypted_private.key", "passphrase");
var algs = (List<HostAlgorithm>)key.HostKeyAlgorithms;
// Keep rsa-sha2-512
algs.RemoveAt(2);
algs.RemoveAt(1);
SftpClient client = new SftpClient("host", 5022, "user", key);
// the rest |
|
Thanks! |
|
I downloaded JSCAPE server and unfortunately I can't reproduce the problem 🙁 |
|
We just started with this issue since the update also and can confirm that the first solution gets us back up and working. The main one in question comes back with SSH-2.0-Axway.Gateway as the host info. |
|
Ok thanks, the plot thickens. If anyone is willing to get some rudimentary diagnostics, that could be helpful (but might not be 😄) You will need a debug build of the library, ideally containing b4c8291. Download the repo git clone https://github.com/sshnet/SSH.NET.git
cd SSH.NET
dotnet buildIn your project, remove any nuget reference to SSH.NET and add a reference to Renci.SshNet.dll in Configure diagnostics per the instructions in https://github.com/sshnet/SSH.NET/blob/54d01621aa54ce16a1523172b12be3bc9add898a/src/Renci.SshNet/Abstractions/DiagnosticAbstraction.cs (sorry). I.e. using Renci.SshNet.Abstractions;
DiagnosticAbstraction.Source.Switch = new SourceSwitch("sourceSwitch", "Verbose");
DiagnosticAbstraction.Source.Listeners.Remove("Default");
DiagnosticAbstraction.Source.Listeners.Add(new ConsoleTraceListener());
DiagnosticAbstraction.Source.Listeners.Add(new TextWriterTraceListener("trace.log"));Then run and dump the output of trace.log (in your bin/Debug folder) here. |
|
I am running into the same problem after upgrading from 2020.0.2 to 2023.0.0. Here is the stack trace I get: ❌ The following has no effect: ❌ The following still gives me the same error: ✔️ I am able to connect successfully if I do this: ✔️ This also works: It seems like it works successfully as long as I have tried connecting to three different servers. Only one of them fails to connect without the above mentioned modifications to the Diagnostics - Example 1When I run the diagnostics using a build based on the latest commit in the The These two lines seem to be of particular interest: Diagnostics - Example 2I am able to connect successfully when In this scenario, here is what it prints to the console: These lines seem to be of particular interest: Diagnostics - Example 3I have tried (unsuccessfully) to reproduce the problem using a local installation of OpenSSH with the following configuration. I am still able to connect successfully with the above configuration. Here is the output: These lines seem to be of particular interest: In the third example above, it looks like the client negotiates with the server through a trial and error process until one of the key types is accepted by the server. In the first example, however, it looks like the server rudely disconnects if the first key type offered is not one that it accepts. Looking at the code, I can see in
Running through the erroneous scenario in the first example, the main thread never makes it past the wait on line 95 above. While the main thread is waiting, a secondary thread running the message listener in
I'm in way over my head here. I'm not sure what the correct behavior should be. Is the server violating protocol by dropping the connection instead of returning a polite denial? Is the client being rude by attempting to use a key type that is not accepted by the server? Is the protocol ambiguous in this case? |
|
Thanks very much @jkillingsworth. So we have 1x JSCAPE and 2x Axway.Gateway
That's my naïve view, based on https://datatracker.ietf.org/doc/html/rfc4252#section-7:
which seems against protocol. I have been wondering what other clients do. It seems like WinSCP/PuTTY only use ssh-rsa signatures for client authentication by default unless the sha2 variants have been specified by the server via the SSH.NET does not currently implement extension negotiation, so we should probably always try ssh-rsa first until it supports server-sig-algs, at which point it could use the strongest variant specified. |
|
@Rob-Hague Thanks for taking a look at this. I appreciate your help. If my understanding is correct, this is what is happening: When the client sends a |
|
Yes that's my understanding too |
|
The 2023.0.1 version has been released to Nuget: https://www.nuget.org/packages/SSH.NET/2023.0.1 |
|
thank you! |
I'm getting a Renci.SshNet.Common.SshConnectionException: An established connection was aborted by the server. after upgrading to SSH.NET 2023.0.0
my code still works fine with SSH.NET 2020.0.2
I'm using a private key file to connect (connecting with another server where I have just user/pw still works fine with 2023.0.0)
I have tried this with .NET Framework 4.8 and .NET 7.0, neither works
could you please look into this?
The text was updated successfully, but these errors were encountered: