0 votes
by (140 points)

Hi,

I am trying to use Rebex.SFTP to connect to an SFTP server using PrivateSSHKey.

        await _sftpClient.ConnectAsync("mysftpserver.com", 22);
        var privateKey = new SshPrivateKey(@"d:\ADF\privatekey.rsa");
        await _sftpClient.LoginAsync("myUserName", privateKey);

I am getting an Exception when the login is being processed:

Rebex.Net.SshException: A public key corresponding to the supplied private key was not accepted by the server or the user name is incorrect.

I have successfully connected to the SFTP server using FileZilla FTP Client, using the same RSA encrypted Private Key, and the same User login.

I have enabled debugging in the SFTP Client - here is the log:

2022-11-22 16:14:37.973 Opening log file.
2022-11-22 16:14:37.981 INFO FileLogWriter(1)[1] Info: Assembly: Rebex.Common R6.9 for .NET 6.0
2022-11-22 16:14:38.008 INFO FileLogWriter(1)[1] Info: Platform: Windows 10.0.19044 64-bit; CLR: .NET 6.0.11
2022-11-22 16:14:38.011 DEBUG FileLogWriter(1)[1] Info: Culture: da; windows-1252
2022-11-22 16:14:42.452 INFO Sftp(1)[3] Info: Connecting to andfrsftp.blob.core.windows.net:22 using Sftp.
2022-11-22 16:14:42.452 INFO Sftp(1)[3] Info: Assembly: Rebex.Sftp R6.9 for .NET 6.0 (Trial)
2022-11-22 16:14:42.453 INFO Sftp(1)[3] Info: Platform: Windows 10.0.19044 64-bit; CLR: .NET 6.0.11
2022-11-22 16:14:42.453 DEBUG Sftp(1)[3] Info: Culture: da; windows-1252
2022-11-22 16:14:42.476 DEBUG Sftp(1)[3] Proxy: Resolving 'andfrsftp.blob.core.windows.net'.
2022-11-22 16:14:42.508 DEBUG Sftp(1)[3] Proxy: Connecting to 20.150.42.228:22 (no proxy).
2022-11-22 16:14:42.547 DEBUG Sftp(1)[3] Proxy: Connection established.
2022-11-22 16:14:42.567 DEBUG Sftp(1)[3] SSH: Server is 'SSH-2.0-AzureSSH1.0.0'.
2022-11-22 16:14:42.579 INFO Sftp(1)[3] SSH: Negotiation started.
2022-11-22 16:14:42.699 DEBUG Sftp(1)[3] SSH: Negotiating key.
2022-11-22 16:14:42.735 DEBUG Sftp(1)[3] SSH: Validating 'rsa-sha2-256' signature.
2022-11-22 16:14:42.757 DEBUG Sftp(1)[3] SSH: Received 2048-bit RSA server key (minimum allowed size is 1023 bits).
2022-11-22 16:14:42.788 INFO Sftp(1)[3] SSH: Negotiation finished.
2022-11-22 16:14:42.788 INFO Sftp(1)[3] Info: Server: SSH-2.0-AzureSSH
1.0.0
2022-11-22 16:14:42.789 INFO Sftp(1)[3] Info: Fingerprint (MD5): a1:4c:5f:13:43:79:8a:40:fb:cd:23:3c:99:69:95:43
2022-11-22 16:14:42.790 INFO Sftp(1)[3] Info: Fingerprint (SHA-256): IeHrQ+N6WAdLMKSMsJiML4XqMrkF1kyOiTeTjh1PFyc
2022-11-22 16:14:42.790 INFO Sftp(1)[3] Info: Cipher info: SSH 2.0, ecdh-sha2-nistp256, rsa-sha2-256, aes256-gcm@openssh.com/aes256-gcm@openssh.com
2022-11-22 16:14:42.840 DEBUG Sftp(1)[11] SSH: Server supports extension negotiation.
2022-11-22 16:14:42.936 DEBUG Sftp(1)[3] SSH: Allowed authentication methods for 'andfrsftp.ftproot.andfrkey': publickey, password.
2022-11-22 16:14:42.937 DEBUG Sftp(1)[3] SSH: Trying public key authentication for 'andfrsftp.ftproot.andfrkey' using 'rsa-sha2-256'.
2022-11-22 16:14:43.009 ERROR Sftp(1)[3] SSH: Rebex.Net.SshException: A public key corresponding to the supplied private key was not accepted by the server or the user name is incorrect.
at Rebex.Net.SshSession.oxdya(String p0, String p1, SshPrivateKey p2, SshGssApiCredentials p3, Boolean p4)

I hope you are able to help :)

Kind regards
Anders

by (140 points)
Hi,

Thanks for your reply. Instead of using GetDownloadStream, im trying to get performance by using GetFileAsync. However, when I use the Method GetFileAsync, it fails after having transffered some parts of the file - around 450kb - 4Mb (Random) of a 209 mb file.

....
2022-11-25 13:37:05.676 DEBUG Sftp(1)[3] Batch: Multi-file operation done.
2022-11-25 13:37:07.785 INFO Sftp(1)[5] Command: SSH_FXP_OPEN (9, '/some new folder/Demo of scaling Azure Functions-20221116_150826-Meeting Recording.mp4', 1)
2022-11-25 13:37:07.819 INFO Sftp(1)[5] Response: SSH_FXP_HANDLE (9, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330)
2022-11-25 13:37:07.822 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (10, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 0, 28672)
2022-11-25 13:37:07.822 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (11, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 28672, 28672)
2022-11-25 13:37:07.822 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (12, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 57344, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (13, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 86016, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (14, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 114688, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (15, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 143360, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (16, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 172032, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (17, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 200704, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (18, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 229376, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (19, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 258048, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (20, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 286720, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (21, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 315392, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (22, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 344064, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (23, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 372736, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (24, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 401408, 28672)
2022-11-25 13:37:07.823 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (25, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 430080, 28672)
2022-11-25 13:37:07.933 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (10, 28672 bytes)
2022-11-25 13:37:07.933 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (26, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 458752, 28672)
2022-11-25 13:37:07.956 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (11, 28672 bytes)
2022-11-25 13:37:07.956 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (27, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 487424, 28672)
2022-11-25 13:37:07.956 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (12, 28672 bytes)
2022-11-25 13:37:07.956 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (28, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 516096, 28672)
2022-11-25 13:37:07.981 DEBUG Sftp(1)[5] SSH: Adjusted local receive window size: 15746 -> 131072.
2022-11-25 13:37:07.981 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (13, 28672 bytes)
2022-11-25 13:37:07.981 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (29, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 544768, 28672)
2022-11-25 13:37:07.981 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (14, 28672 bytes)
2022-11-25 13:37:07.981 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (30, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 573440, 28672)
2022-11-25 13:37:07.981 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (15, 28672 bytes)
2022-11-25 13:37:07.981 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (31, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 602112, 28672)
2022-11-25 13:37:07.984 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (16, 28672 bytes)
2022-11-25 13:37:07.984 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (32, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 630784, 28672)
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] SSH: Adjusted local receive window size: 16332 -> 131072.
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (17, 28672 bytes)
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (33, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 659456, 28672)
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (18, 28672 bytes)
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (34, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 688128, 28672)
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (19, 28672 bytes)
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (35, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 716800, 28672)
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] SSH: Adjusted local receive window size: 16332 -> 106457.
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (20, 28672 bytes)
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (36, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 745472, 28672)
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (21, 28672 bytes)
2022-11-25 13:37:08.010 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (37, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 774144, 28672)
2022-11-25 13:37:08.059 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (22, 28672 bytes)
2022-11-25 13:37:08.059 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (38, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 802816, 28672)
2022-11-25 13:37:08.060 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (23, 28672 bytes)
2022-11-25 13:37:08.060 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (39, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 831488, 28672)
2022-11-25 13:37:08.061 ERROR Sftp(1)[11] SSH: SSH protocol violation by the remote side.
2022-11-25 13:37:08.063 DEBUG Sftp(1)[5] SSH: Adjusted local receive window size: 20402 -> 131072.
2022-11-25 13:37:08.063 DEBUG Sftp(1)[5] Response: SSH_FXP_DATA (24, 28672 bytes)
2022-11-25 13:37:08.063 DEBUG Sftp(1)[5] Command: SSH_FXP_READ (40, 0x30346539353863322D326465392D343930352D383531312D356130336239613336343330, 860160, 28672)
2022-11-25 13:37:08.098 ERROR Sftp(1)[11] SSH: Error occured while receiving SSH packet: Rebex.Net.SshException: SSH protocol violation by the remote side.
   at Rebex.Net.SshChannel.jymuz(Byte[] p0, Int32 p1, Int32 p2)
   at Rebex.Net.SshSession.wyjrn(Byte[] p0, Int32 p1, Int32 p2)
   at Rebex.Net.SshSession.xjjoo()
   at Rebex.Net.SshSession.ifbeg()
2022-11-25 13:37:08.103 ERROR Sftp(1)[5] SSH: Rebex.Net.SshException: SSH protocol violation by the remote side.
 ---> Rebex.Net.SshException: SSH protocol violation by the remote side.
   at Rebex.Net.SshChannel.jymuz(Byte[] p0, Int32 p1, Int32 p2)
   at Rebex.Net.SshSession.wyjrn(Byte[] p0, Int32 p1, Int32 p2)
   at Rebex.Net.SshSession.xjjoo()
   at Rebex.Net.SshSession.ifbeg()
   --- End of inner exception stack trace ---
   at Rebex.Net.SshSession.umxnl()
   at Rebex.Net.SshSession.wkprm[T,S](onjvl`2 p0, Int32 p1, yzjut p2, S p3, T p4, T p5)
   at Rebex.Net.SshSession.bbbes[T,S](onjvl`2 p0, S p1)
   at Rebex.Net.SshChannel.pvwgd[T,S](onjvl`2 p0, S p1)
   at Rebex.Net.SshChannel.uazfl(Byte[] p0, Int32 p1, Int32 p2)
   at Rebex.Net.SshChannel.Receive(Byte[] buffer, Int32 offset, Int32 count)
2022-11-25 13:37:08.103 DEBUG Sftp(1)[5] Info: Waiting for 15 outstanding read requests to arrive.
2022-11-25 13:37:08.105 ERROR Sftp(1)[5] Info: Rebex.Net.SftpException: The server has closed the connection.
   at xuxsl.psvpz.evdio(Int32 p0)
   at xuxsl.psvpz.jxdek(aaskk& p0)
   at xuxsl.psvpz.ytmxj(UInt32 p0, Boolean p1)
   at xuxsl.psvpz.oluec(UInt32 p0, tyohx p1)
   at Rebex.Net.Sftp.xptro(tyohx p0, String p1, vcaer p2, Int64 p3, Int64 p4, usvmw p5)
by (148k points)
Thanks for reporting this - it actually sheds more light onto the previous "SSH protocol violation by the remote side" occurrence. Apparently, the authors of Azure SSH invented additional requirements of their own along the lines of "SFTP client must ensure that its receive window size is large enough for receiving the server response at the time of sending the request". We will add a workaround for this to the next release. In the meantime, setting "_sftpClient.Settings.UseLargeBuffers = true" should resolve the issue (again, this will make Rebex SFTP behave a bit more like FileZilla).
by (140 points)
Hi

Thanks. Using the "_sftpClient.Settings.UseLargeBuffers = true" did the trick. I can now download at full speed.
by (140 points)
Which version will the hotfix be released in?
by (148k points)
It will be released in version R6.10.

1 Answer

0 votes
by (140 points)
edited by

Apologies to continue on this thread but I have an issue that seems very closely related here.

It was reported above that this would be resolved in 6.10. We are currently using 6.9 (6.0.8348.0) so I was testing using the Trial Rebex SFTP R6.10 for .NET 4.6-4.8 6.0.8372.0(I am not a developer)and am still having the same issue.

The Debug results in the following IPADDRESS and USERNAME replaced.

Welcome to Rebex SFTP!
14:45:37.172 Info Info: Connecting to IPADDRESS:22 using Sftp.
14:45:37.175 Info Info: Assembly: Rebex.Sftp R6.10 for .NET 4.6-4.8 (Trial)
14:45:37.175 Info Info: Platform: Windows 6.2.9200 32-bit; CLR: 4.0.30319.42000
14:45:37.176 Debug Info: Culture: en; Windows-1252
14:45:37.188 Debug Proxy: Connecting to IPADDRESS:22 (no proxy).
14:45:37.207 Debug Proxy: Connection established.
14:45:37.221 Debug SSH: Server is 'SSH-2.0-srtSSHServer_19.00'.
14:45:37.227 Info SSH: Negotiation started.
14:45:37.335 Debug SSH: Group exchange.
14:45:37.463 Debug SSH: Negotiating key.
14:45:37.478 Debug SSH: Received 2048-bit Diffie-Hellman prime (minimum allowed size is 1024 bits).
14:45:37.513 Debug SSH: Validating 'rsa-sha2-256' signature.
14:45:37.532 Debug SSH: Received 1024-bit RSA server key (minimum allowed size is 1023 bits).
14:45:57.280 Info SSH: Negotiation finished.
14:45:57.280 Info Info: Server: SSH-2.0-srtSSHServer_19.00
14:45:57.280 Info Info: Fingerprint (MD5): 8c:03:71:19:9f:e2:0f:e5:26:9c:06:df:ec:b7:45:99
14:45:57.280 Info Info: Fingerprint (SHA-256): Cv78auli0BEDW9ic2+l8NO1bC8MYVs8xtAApwzu9ZDI
14:45:57.281 Info Info: Cipher info: SSH 2.0, diffie-hellman-group-exchange-sha256, rsa-sha2-256, aes256-ctr/aes256-ctr, hmac-sha2-256/hmac-sha2-256
14:45:57.346 Debug SSH: Allowed authentication methods for 'USERNAME': publickey, password.
14:45:57.347 Debug SSH: Trying public key authentication for 'USERNAME' using 'rsa-sha2-256' (SHA256:bObKuB+t7YtKrYpi/0aQPiDEDvc7X+szWmCbGN5ibx4)
14:45:57.482 Error SSH: Rebex.Net.SshException: A public key corresponding to the supplied private key was not accepted by the server or the user name is incorrect.
   at Rebex.Net.SshSession.azxlb(String p0, String p1, SshPrivateKey p2, SshGssApiCredentials p3, Boolean p4)


14:32:09    Status: Connecting to IPADDRESS...
14:32:09    Trace:  Going to execute C:\Program Files\FileZilla FTP Client\fzsftp.exe
14:32:09    Response:   fzSftp started, protocol_version=11
14:32:09    Trace:  CSftpConnectOpData::ParseResponse() in state 0
14:32:09    Trace:  CControlSocket::SendNextCommand()
14:32:09    Trace:  CSftpConnectOpData::Send() in state 2
14:32:09    Command:    keyfile "C:\Clients\Private_Key.ppk"
14:32:09    Trace:  CSftpConnectOpData::ParseResponse() in state 2
14:32:09    Trace:  CControlSocket::SendNextCommand()
14:32:09    Trace:  CSftpConnectOpData::Send() in state 3
14:32:09    Command:    open "USERNAME@IPADDRESS" 22
14:32:09    Trace:  Looking up host "IPADDRESS" for SSH connection
14:32:09    Trace:  Connecting to IPADDRESS port 22
14:32:09    Trace:  We claim version: SSH-2.0-FileZilla_3.60.1
14:32:09    Trace:  Connected to IPADDRESS
14:32:09    Trace:  Remote version: SSH-2.0-srtSSHServer_19.00
14:32:09    Trace:  Using SSH protocol version 2
14:32:09    Trace:  Doing Diffie-Hellman group exchange
14:32:09    Trace:  Doing Diffie-Hellman key exchange using 2070-bit modulus and hash SHA-256 (unaccelerated) with a server-supplied group
14:32:09    Trace:  Server also has rsa-sha2-256/ssh-rsa host keys, but we don't know any of them
14:32:09    Trace:  Host key fingerprint is:
14:32:09    Trace:  ssh-rsa 1024 SHA256:Cv78auli0BEDW9ic2+l8NO1bC8MYVs8xtAApwzu9ZDI
14:32:09    Trace:  CSftpControlSocket::SetAsyncRequestReply
14:32:09    Command:    Trust new Hostkey: Once
14:32:09    Trace:  Initialised AES-256 SDCTR (AES-NI accelerated) outbound encryption
14:32:09    Trace:  Initialised HMAC-SHA-256 (unaccelerated) outbound MAC algorithm
14:32:09    Trace:  Initialised AES-256 SDCTR (AES-NI accelerated) inbound encryption
14:32:09    Trace:  Initialised HMAC-SHA-256 (unaccelerated) inbound MAC algorithm
14:32:09    Trace:  Successfully loaded 1 key pair from file
14:32:09    Status: Using username "USERNAME". 
14:32:09    Trace:  Offered public key from "C:\Clients\Private_Key.ppk"
14:32:10    Trace:  Offer of public key accepted, trying to authenticate using it.
14:32:10    Trace:  Sent public key signature
14:32:10    Trace:  Access granted
14:32:10    Trace:  Opening main session channel
14:32:10    Trace:  Opened main channel
14:32:10    Trace:  Started a shell/command
14:32:10    Status: Connected to IPADDRESS

Filezilla seems to connect successfully. Any extra thoughts here please?

Many thanks

Rich

by (148k points)
If this is indeed a similar issue, the following code should help. Please give it a try.

    SshPrivateKey key = ...;

    var sftp = new Sftp();
    sftp.LogWriter = ...;
    sftp.Settings.EnsureKeyAcceptable = true;
    Rebex.Security.Cryptography.CryptoHelper.SetOption(sftp.Settings.SshParameters, "ClientKeyAlgorithms", new string[] { "ssh-rsa" });
    sftp.Connect("IPADDRESS", 22);
    sftp.Login("USERNAME", key);
by (140 points)
Thanks for the super quick response Lukas!   I would need to get this to my dev team to implement.  I was trying to ensure that the hotfix that was made available in November listed above, had been applied to 6.1, and expected this to have just worked in Rebex SFTP and then I would get the team to implement the new version of the .DLL's

"Apparently, OpenSSH is using the legacy "ssh-rsa" algorithm (RSA with SHA-1 hash), while Rebex SFTP attempts the new "rsa-sha2-256" algorithm (RSA with SHA-256 hash).

Unfortunately, it's not currently possible to force "ssh-rsa", so we will update Rebex SFTP and mail you a link to try later today."

Is it just that the Hotfix applied now gives the option to force ssh-rsa as you show in your snippet above that wasn't available before so there would be no way of testing this from the Rebext SFTP client for someone with no coding... I am happy to tinker with config files :-) ?  

Maybe a (very) simple question, apologies, but if we use the above and it resolves the issue for this client forcing ssh-rsa and we roll it out, I'm guessing that it will only use this as a last resort as it is a weaker connection option than trying 256 first?

Regards

Rich
by (148k points)
The hotfix announced in November has been available since R6.10, but it only applies to Azure Storage SFTP server. Your server seems to be "srtSSHServer 19.00", and the hotfix won't be applied to it. Instead, CryptoHelper.SetOption has to be used to enforceusage of "ssh-rsa". And the additional EnsureKeyAcceptable makes the authentication exchange more like FileZilla client.
by (140 points)
Thank you Lukas, I'll advise our dev team.
by (140 points)
Hi Lukas, I have just tested the changes you suggested and this seems to have resolved the issue in our testing environment.  Thanks again for the quick response here.

Can I just confirm exactly what this does?  Does it force a connection at ssh-rsa even if the later ssh-rsa2 may be available at the host, or does this just change the sequence of connectivity offered so the legacy one comes first?

Hopefully, it is just a sequence change as I am a little bit twitchy to release this to the entire customer base if this is only affecting one customer if it has to connect using this method.

As I mentioned, I am not a dev, I'm on the Tech Services team, so this may seem like a simple question to all out there, apologies!  Rich
by (148k points)
Hi AptWat, you are right to be a little bit twitchy about releasing this to the entire customer base, although it's not as bad as it sounds:

The "ClientKeyAlgorithms" option does not actually affect SSH negotiation, and has no effect on encryption or server host key validation (which would still use "rsa-sha2-256", as you can see i the log). What it does affect is client public key authentication - it forces Rebex SFTP to use "ssh-rsa" (RSA with SHA-1) instead of "rsa-sha2-256" (RSA with SHA-256) during client public key authentication even when the server claims or appears to support "rsa-sha2-256".

The effect of the option can be clearly seen in the log. Without the option, there is:
  Trying public key authentication for 'USERNAME' using 'rsa-sha2-256' (...)
And with the option, this becomes:
  Trying public key authentication for 'USERNAME' using 'ssh-rsa' (...)

But still, forcing RSA with SHA-1 for everyone is not a good idea - it's less secure, and even if you didn't care about that, some SFTP servers might actually reject this and require RSA with SHA-2.

Obviously, the proper solution to this issue is to have the servers fixed - both Azure SFTP server and srtSSHServer do support RSA/SHA-2 for server key authentication, and the fact that they refuse it for client key authentication seems to be a bug or an omission. If your clients suffer from this issue, please ask them to report the bug to the server vendor so they can fix it.

In the meantime, you have two options - either make the behavior configurable (such as adding "force legacy RSA/SHA-1 client authentication" to the UI or configuration file), or only enable the option when the application detects "srtSSHServer", like this for example:

            SshPrivateKey key = ...

            var sftp = new Sftp();
            sftp.LogWriter = new ConsoleLogWriter(LogLevel.Debug);
            sftp.Settings.EnsureKeyAcceptable = true;
            sftp.Connect("IPADDRESS", 22);

            // detect 'srtSSHServer' and force 'ssh-rsa' for client authentication
            if (sftp.Session.ServerIdentification.Contains("srtSSHServer_19.", StringComparison.Ordinal))
            {
                Rebex.Security.Cryptography.CryptoHelper.SetOption(sftp.Session.Parameters, "ClientKeyAlgorithms", new string[] { "ssh-rsa" });
            }

            sftp.Login("USERNAME", key);
by (140 points)
Hi Lukas,, once again, I appreciate your time and continued patience here. Your explanation is perfectly clear and the option to check for sshserver is a great suggestion I'll take back to the team, regards Rich
...