Error After Latest Update - Remote side sent SSH2_MSG_EXT_INFO after USERAUTH_SUCCESS

Hi Team,

I hope you're doing well. I updated to the latest version of WinSCP yesterday and ever since then, I have been unable to perform any type of transferring from my file server to my main desktop.

I know that this is WinSCP's doing as I have 3 other devices, all same OS versions, extremely similar software, and only my main desktop was experiencing the issue.

To test, I updated one other device's WinSCP to the latest version and the exact same error started occurring. I have attempted to download files from my File server through the below methods:

• SCP
  
• SFTP
  
• HTTPS
  

All fail after a couple minutes. I believe this has something to do with the TLS/SSL Core update. I was hoping someone could assist with rolling back the above, or if it's not related, work with me to test as this is currently crippling my file transfer capabilities between my file server and main device.

I've attached the WinSCP logs to show the error. All directory listings, hostnames, usernames, etc, have been removed. This is not a permissioning issue as no other device outside of those updated with the latest version of WinSCP are encountering this issue.

NOTE: This is personal use (just mentioning this as I said file server).

Can you please try to find out what version of WinSCP introduced the problem?
You can download all past version of WinSCP from:
https://sourceforge.net/projects/winscp/files/WinSCP/

Good morning, the version that is displayed in the log – WinSCP Version 5.21.1 (Build 12643 2022-06-24), is the one that started causing the issue. Attempting to downgrade WinSCP does not fix the issue. A clean install (deleting all stored preferences, etc) did not fix the issue. Clearing SSL cache also did not fix the issue.

Using alternate software, such as FileZilla, works without issue. If I have a file transfer with WinSCP and FileZilla simultaneously going, WinSCP fails after ~2 minutes, FileZilla completed transferring 10+ files that took ~45 minutes.

So isn't it more likely that the problem was caused by a change (upgrade) on the server at about the same time you have upgraded to WinSCP 5.21.1?

I have already thought of this. I consider this unlikely as the server is Linux based with all automatic updates turned off. I have full control of the server and made no changes. Reviewing the logs on my side show no configuration changes for the last 3 weeks. No other party has access.

Further, I have confirmed that no other utility has this issue. FileZilla, Teracopy, simple SCP, all do not have this issue. The only devices that have this issue are ones that have the latest version of WinSCP installed.

I reimaged one of my devices for testing purposes and had no issues. Installing an older version of WinSCP caused no issues as well. When I updated to the latest version, the issue returned and I could no longer copy for extended periods of time through WinSCP.

To me the single common factor in all of the above is the latest version of WinSCP.

Wafflemonger wrote:

I reimaged one of my devices for testing purposes and had no issues. Installing an older version of WinSCP caused no issues as well. When I updated to the latest version, the issue returned and I could no longer copy for extended periods of time through WinSCP.

And if you downgrade, does it resolve the problem?

A downgrade does not resolve the problem.

Can you please post verbose log files of

1. successful transfer using a newest version of WinSCP that still works (5.21?)
   
2. failed transfer after upgrade to 5.21.1
   
3. failed transfer after downgrade to the same old version
   

I have used WinSCP for several years.... Upgraded to latest version and now cannot do any encrypted transfers only unencrypted.

And now PuTTY won't connect because I can't use any encryption.

The "upgrade notice" mentioned updating something related to SSL so I think that broke it. I talked to my server person and they said it's not on their end. FileZilla and others also work for me.

5.21.1 broke it

Rolling back to 5.19 did not fix the problem. I can try other older versions but out of time on this for today.

@martin: Hey good sir, I just wanted to say I got your message. I will absolutely do this, I just likely won't have it done until after the weekend, or late on Sunday as I am preoccupied until then. I hope that's alright!

Have a great weekend.

@torrid33: So can you provide the information I've asked Wafflemonger for?
I do not understand the relation to PuTTY and encrypted transfers.

@Wafflemonger: No problem.

I have the 5.21.1 and 5.21 logs. I will get the one that works as soon as possible. Again, I am terribly sorry for all the delays, work has been crazy these last couple days.

Also, I wasn't sure what logging to use, so I used Debug 1. Not sure if there was a specific way you wanted me to do this. If there is, please let me know and I'll re-upload.

@Wafflemonger: Thanks. I'll wait for the logs of the working version.

Good morning/afternoon, depending on your timezone.

I apologize for the delay, lots of things occurred in life all at once. Please find attached the successful transfer. I transferred a large file to confirm the connection wouldn't be killed after a certain amount of time. I also transferred a different file than previously, as I wanted to confirm it wasn't just a 1 time thing.

After testing 4 file transfers, all completed on the device that was never updated. Please find said log file attached containing one of said successful transfers.

Thanks. Though that's 5.19.3. I've asked for:

1. successful transfer using a newest version of WinSCP that still works (5.21?)
   
2. failed transfer after upgrade to 5.21.1
   
3. failed transfer after downgrade to the same old version

So does 5.21 ever work? Or should the version in 1) and 3) steps rather be 5.19.3?

Hi Martin,

I tested Version 5.19.6, which worked properly and 5.21, which shows the issue reported here. After each attempt, I uninstalled the software an installed another version of it.
So in short:
5.19.6 is the latest version without this issue.
5.21 and 5.21.1 5.21.6 and 5.21.7 are affected of this problem.

Logs in Debug-1 mode are attached for Versions 5.19.6 and 5.21 (see WinSCP-Logs.zip).

@Volker: It seems to be an issue with OpenSSH 7.2 on Ubuntu.
See also PuTTY Fatal Error: Remote side unexpectedly closed network connection
I do not think it's PuTTY/WinSCP problem. It's just that PuTTY/WinSCP added an additional check that wasn't there before.
Cannot you upgrade your server?

Hello all.

I am also affected by this issue and can confirm the theory: transferring a 8GiB file with WinSCP 5.19 works fine, with 5.21 the file transfer breaks up with the following lines:
And I can confirm that the same file transfer also works with WinSCP 5.21 if the OpenSSH configuration parameter UsePrivilegeSeparation is set to yes on the server.

I would like to thank all participating persons here!

@martin: OpenSSH is running on an Appliance running on SLES12-SP5. I'm in touch with the vendor of that Appliance in order to get a fix for this issue.

@spintike: Thanks for sharing your findings! Though I'm not sure what "theory" do you refer to.

Hi there,
I am getting this error

Remote side sent SSH2_MSG_EXT_INFO not either preceded by NEWKEYS or followed by USERAUTH_SUCCESS Authentication failed.

since upgrading from version 5.21.7 to 6.3.1

I am using the .NET library and open attempting to open the connection, I received the exception:

"Authentication failed.\r\nAuthentication log (see session log for details):\nUsing username \"******\".\nServer refused our key.\nAccess denied.\n\r\nAuthentication failed."

Is there properties or SessionOptions I can set to hide the SSH bug of the SFTP server or do I have to revert back to 5.21.7?

Thank you

@JoeBlack: If I understand your question correctly, you are looking for BugRekey2=2 raw site settings.
https://winscp.net/eng/docs/rawsettings