Can't connect (SCP, SSH) in Xamarin Android

[stealthrabbi]

Calling Connect() with an SSH or SCP client (and likely others) causes this exception. Does this library not work in Xamarin Android?

I don't see where in this library ti's throwing NotImplementedException, so I'm guessing something missing in Mono / .NET Standard?

2021-04-15 12:29:05.030 16384-16427/? E/MySessionStarter: Failed uploading file: System.NotImplementedException: The method or operation is not implemented.
      at Renci.SshNet.Session.WaitOnHandle (System.Threading.WaitHandle waitHandle, System.TimeSpan timeout) [0x00041] in <c7169cd606324a41b931acc40c516428>:0 
      at Renci.SshNet.Session.WaitOnHandle (System.Threading.WaitHandle waitHandle) [0x0000d] in <c7169cd606324a41b931acc40c516428>:0 
      at Renci.SshNet.Session.Connect () [0x0017b] in <c7169cd606324a41b931acc40c516428>:0 
      at Renci.SshNet.BaseClient.CreateAndConnectSession () [0x00053] in <c7169cd606324a41b931acc40c516428>:0 
      at Renci.SshNet.BaseClient.Connect () [0x0001f] in <c7169cd606324a41b931acc40c516428>:0 
    ....
    ```

[drwtsn32x]

Did you solve this yet? What version of mono are you using?

[stealthrabbi]

Not solved. I don't know what version of Mono I'm using. I believe it was roughly the latest Xamarin.

[drwtsn32x]

When you get a chance, if you could check the mono version that'd be great....

$ mono --version

I'm exploring possibly the same issue with a different product that uses the SSH.NET library. Wondering if the mono version is the culprit.

[stealthrabbi]

I don't explicitly have mono installed -- that's not needed for Xamarin work. The Mono.Android assembly that VS is using for the Xamarin Android project is in a folder named C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v9.0, but the actual DLL has a Product version of 11.0.2.0;

[drwtsn32x]

Ok, on the other project I'm working on we discovered that mono doesn't support ECDSA keys. SSH.NET library will throw the NotImplemented exception when it's running via mono. (It works fine when using native .NET on Windows though.)

So you might be able to "solve" your problem by not using an ECDSA key...

[stealthrabbi]

What you say about the keys may be right, but I think my issue is happening way before a connection. It's related to Session.WaitOnHandle being not implemented.

[ts678]

It's related to Session.WaitOnHandle being not implemented.

It seems Session.WaitOnHandle is in https://github.com/sshnet/SSH.NET/blob/develop/src/Renci.SshNet/Session.cs
You can see comments there about the receive thread. I'm not an SSH.NET developer. It'd be nice if they can help.

It might be waiting at the below for the receive thread to either receive, or find an exception, and it got exception:

SSH.NET/src/Renci.SshNet/Session.cs

Line 852 in f072c5f

internal void WaitOnHandle(WaitHandle waitHandle, TimeSpan timeout)

I think my issue is happening way before a connection

The stack trace names suggest that it's working on connect, but it likely died before SSH connection was finished.
The behavior we see with certain SFTP servers such as Bitvise (but not OpenSSH, at least so far) is a failure after a

Server: Elliptic Curve Diffie-Hellman Key Exchange Reply, New Keys
Message Code: Elliptic Curve Diffie-Hellman Key Exchange Reply (31)
is received, containing
KEX host key (type: ecdsa-sha2-nistp384)
I think the received protocol is RFC 5656 ECDH Key Exchange here.

Processing of that server SSH_MSG_KEX_ECDH_REPLY might be here:

SSH.NET/src/Renci.SshNet/Session.cs

Lines 1298 to 1302 in f072c5f

	/// <summary>
	/// Called when <see cref="NewKeysMessage"/> message received.
	/// </summary>
	/// <param name="message"><see cref="NewKeysMessage"/> message.</param>
	internal void OnNewKeysReceived(NewKeysMessage message)

and at some point the key from the server might hit here:

SSH.NET/src/Renci.SshNet/Security/Cryptography/EcdsaKey.cs

Lines 238 to 242 in a5bd08d

	/// <summary>
	/// Initializes a new instance of the <see cref="EcdsaKey"/> class.
	/// </summary>
	/// <param name="data">DER encoded private key data.</param>
	public EcdsaKey(byte[] data)

ECDsa Class and ECDsaCng Class get involved, and so maybe it hits the NotImplementedException around here.

NotImplementedException has been in ECDsaCng.cs a long time, maybe added here, then later exposed through
Support newer SSH Ciphers and MACs #53. If you're still on the 2016 release, ignore all this. It applies to 2020's.

Any SSH.NET developer comments? Could these very welcome new capabilities be exposing an old gap in mono?
Please forgive any mistakes in the details. I don't have a debugger, or know the protocol or the code all that well.

[ts678]

I'm noticing the 2017 mono change did a similar NotImplementedException to RsaCng.cs just below ECDsaCng.cs

[drwtsn32x]

(but not OpenSSH, at least so far)

I was able to reproduce with an OpenSSH server by using an ECDSA key.

[Joannick]

Hi friend,
so did you found a solution about this? I've seen an other solution is Rebex SFTP Nugget but licence is 350$.
Thanks

[stealthrabbi]

My solution was in Xamarin, to create a binding to the JSCH java library and use that in my xamarin android proj.

[ts678]

A workaround is try new ECDsaCng() to see if it's implemented. If exception occurs, go through HostKeyAlgorithms.Keys, and HostKeyAlgorithms.Remove(key) the ones beginning with ecdsa (inspired by Limit what algorithms or ciphers are used #730).