Thank you for the quick support and fix!

Thanks for testing the fix and for all your help and persistence! :)

Thank you.

I removed the detached cert from the manually created registry entries and then tested the following, which all worked:

OpenSSH 7.4 and regression on OpenSSH 8.0 machine:
Key with Embedded cert SCP
Key with Embedded cert SFTP
(of course, the below tests, re-added the detached cert to the registry):
Key and standalone cert SCP
Key and standalone cert SFTP

Thanks. The fix actually depended on the other commit. So I took both.

I'm sending you an email with a development version of WinSCP to the address you have used to register on this forum.

Sounds good. Thank you!

Actually, are you just taking the patch? If so, this one is related.. although if you're blocking key with embedded cert + standalone cert at the same time, I'm not sure if this is needed:
https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=cfe6fd95a77202a77ba552437ab0ead5ebd11316

If this bug didn't exist, I wouldn't have been able to get the key w/embedded cert + external cert, to work either. IE, it 'worked' for me, due to this bug :-) Now that the root-cause is fixed, fixing this, doesn't break my connectivity, if I use 'either' the embedded cert, OR the non-embedded cert + standalone cert.

Ok, thanks!

I'll include the fix into upcoming version of WinSCP, even if it is not updated to complete 0.79.
Issue 2188 – Work around key algorithm naming change in OpenSSH 7.7 and older

I emailed Simon two days ago and haven't received a response. Maybe you could try emailing him directly?

Thanks

Thanks for taking care of this! Do you have any information from Simon regarding final release of 0.79?

The fix for servers using OpenSSH 7.x is in the PuTTY 0.79 pre-release
https://www.chiark.greenend.org.uk/~sgtatham/putty/prerel.html

The Git description:

When you send a "publickey" USERAUTH_REQUEST containing a certified
RSA key, and you want to use a SHA-2 based RSA algorithm, modern
OpenSSH expects you to send the algorithm string as
rsa-sha2-NNN-cert-v01@openssh.com. But 7.7 and earlier didn't
recognise those names, and expected the algorithm string in the
userauth request packet to be ssh-rsa-cert-v01@... and would then
follow it with an rsa-sha2-NNN signature.

OpenSSH itself has a bug workaround for its own older versions. Follow
suit.

Thanks!

Thanks. I contacted the PuTTY team, prior to seeing your post.

The VM with the issue is running Centos 7.9 (still supported), in which the latest version of OpenSSH, is 7.4.
It's, "advertising a willingness to accept SHA-512 signatures, but is then not accepting one when PuTTY offers it."
Simon has sent me an update which works with OpenSSH 7.4. I've asked him if this will make it into 0.79. I'll get back to you.

Thanks!

Thanks. Please cc me, when reporting to PuTTY team.
Yes, that will do. Or you can add the same value to Registry.

Thanks. ok, will do.

In the meantime, until PuTTY is fixed (hopefully they do fix it), what's a reasonable way of getting WinSCP to work, without Admin privileges?

I guess changing to ini file config and adding a [m]DetachedCertificate=[/m] listing would be one way. Is there a better way?

Thanks

Ok, then it was all misunderstanding. Yes, there's indeed such change in behavior between 6.0.1 and 6.0.
Regarding the actual authentication issue, I believe it should not behave the way you describe. It might be a bug in PuTTY code. Please report it:
https://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html

Thank you. I attached the ppk and cert files.

The key/cert behavior is the SAME for both versions of WinSCP 6.0.x and PuTTY.
All require me to use both the key with embedded cert, plus the standalone cert.
Using a key with an embedded cert by itself, doesn't work. Using a key without an embedded cert + standalone cert doesn't work.

The two logs I included earlier are embedded cert, without standalone cert, which doesn't work and embedded cert, with standalone cert, which does work.

This is for sshing into an Azure VM, using Azure AD and OpenSSH. No idea why this is the behavior. Of course, MS' webpage just says that now that PuTTY supports OpenSSH certificates, it can be used. It doesn't say anything about specific configuration for PuTTY.

WinSCP doesn't directly support entering in both embedded key, plus standalone cert.
In 6.0.0, I was able to enter in a non-embedded cert, plus cert, then change to an embedded cert and WinSCP would use both of them. In 6.0.1, once I changed to an embedded cert, the standalone cert disappeared from the registry (even though initially it was still seen greyed out in the UI). I was able to enter in the standalone cert using the registry and the connection worked.

In either case, if this is a valid situation, entering in a key with an embedded cert, should still allow the standalone key to be entered and used. PuTTY allows this. It doesn't grey out the standalone cert box, when a key with an embedded cert is supplied.

Thanks again!

Thanks. But you didn't upload the logs from WinSCP 6.0, where you claim that both scenarios works. Can you also post contents of both the ppk and certificate files (with private parts of the ppk file removed obviously – those marked Private-Lines)?

I uploaded tests with just embedded cert, and with embedded cert + standalone cert.
Data has been consistently sanitized (search/replace) between the two files.

Thanks again!

I captured logs with the 3 cert scenarios.
Is there an existing script to modify sensitive data in logs?

Thanks

Sorry, I'm lost. This is getting no where.
I still do not understand the alleged change between 6.0 and 6.0.1. I do not think there's any. Neither I believe there's anything like "requires the OpenSSH cert BOTH embedded in the key and standalone". There's only one certificate at any given time. And the server cannot even tell where did the certificate came from.

If you believe otherwise, we need some hard evidence. Not assumptions.

I'll try explaining again.

The VM I'm attaching to requires the OpenSSH cert BOTH embedded in the key and standalone. I've asked about that and it seems they can't do anything to change that behavior.

6.0 doesn't directly support this. Once I put in the key WITH the embedded cert, it greys out the cert field. As such, I could temporarily put in a key WITHOUT an embedded cert, add in a cert to the cert field and then go back and add a key with an embedded cert. Not the best situation, but doable.

6.0.1, I could do the above steps, but in reality, it no longer has the standalone cert in the configuration, after I change back to the key with the embedded cert. I could, though, go into the registry (and I'd think, do via config file, if I changed it to use the config file???) and manually add the standalone cert, after the embedded key is configured via the UI.

Hopefully I explained myself better this time.

Thanks!

I've understood that 6.0.1 and 6.0 behave different with the same configuration (one works, one not). So I wanted a log of that different behaviour. Have I misunderstood?

I'm not sure what you want me to log. The difference is in the behavior in the configuration screens. Is there a way to turn on logging for the configuration screens?

@dr1818: Please download 6.0 from:
https://sourceforge.net/projects/winscp/files/WinSCP/

Thanks. I don't have the old 6.0 logs anymore.

For some reason, to connect to this VM, I need to have the OpenSSH certificate imported into the key + have the certificate separate as well. Having either one, without the other, doesn't allow me to connect.

In 6.0, I was able to specify both at the same time, in a roundabout way. I'd specify a key without the cert so that I could then add the cer and then the specify the key with the cert. In 6.0 it would actually save both the Key+cert and the cert itself and use it. For 6.0.1, I'm able to enter both, but it doesn't save the cert. I was able to add the cert to the registry and it used it.

I've asked folks on this end, why I need both, but haven't gotten anywhere with that. I don't know how usual this is.

Thanks!

@dr1818: Can you post logs from both 6.0.1 and 6.0 showing the difference you experience?

I'm not sure what you mean by "set both via the registry"? Were you able to set some WinSCP session settings via registry that you were not able to set via the GUI?

OK, for some reason, I need the certificate BOTH inside the key and separately.
If I have one OR the other, it doesn't authenticate.

I have the same issue inside PuTTY itself.

For the first 6.0 beta, I was able to have both set at the same time via the UI.
In this beta, I am not. I was able to set both via the registry and both SCP and SFTP work.

Thanks

Thanks.
The directory differences aren't real. When I was cleaning the logs, I accidentally didn't use the same value for both.

Based upon something else I'm seeing, I need to look at this some more, but I don't have the time this moment.

Thanks!

@dr1818: You are using different keys.

For SFTP, you are using:
C:\Users\myaccount\.ssh\az_ssh_config\123.123.123.123\puttyvm.ppk with C:\Users\myaccount\.ssh\az_ssh_config\123.123.123.123\id_rsa.pub-aadcert.pub certificate.

For SCP, you are using:
C:\Users\myaccount\.ssh\ssh_config\123.123.123.123\puttyvm.ppk
And there does not seem to be a matching certificate.

I uploaded the redacted SFTP log privately. Thanks!

@dr1818: Both logs please (SCP and SFTP).

@martin: Done.
Thanks

You can mark the attachment as private.

Even with cleaning the logs, is there a private place to upload them?

Thanks

Please attach complete logs.

I didn't realize before, but in both beta 6.0.0.0 and 6.0.0.1, on a server which requires private key + OpenSSH cert, I'm able to connect using SFTP, but not SCP. I'm able to connect using SCP using Windows native scp.

In the logs, for WinSCP SCP:

For SFTP which succeeds

Thanks

@dr1818: Yes that was about the beta. We do not have any estimate, when the beta turns stable. But it's definitely a month at least, probably more.

Any idea when you expect this version to go live?

There was an earlier comment about the next few days – 2 weeks, which is just about up. That may have been talking about beta, though.

I don't know if you have a typical beta soaking period.

Thanks

@dr1818: Thanks for your feedback.

dr1818 wrote:

@martin: I'm being told only for user authentication.

Beta works for my use-case. Both WinSCP app and key conversion work with OpenSSH cert in key. Thank you!

@hlfritz: Probably within two weeks.

Hello,
any outlook as to when 6.0 will be released?

Thx!

@dr1818: Thanks for your feedback.

@martin: I'm being told only for user authentication.

Thanks

Are you using the certificates for user authentication only? Or also for verifying the hosts?

Thanks from me as well!

Thank you!

NTRU and AES-GCM should come with update to PuTTY 0.78 without more effort.
The OpenSSH certificates might need further effort on WinSCP side. The /keygen part will definitely need some effort. We will see.
Support for OpenSSH certificates is tracked here:
Issue 1873 – Support for OpenSSH certificates for user authentication

Looking forward to the update.

For my use case, I actually need the added, below feature, to actually be able to log in:

Support for OpenSSH certificates, for both user authentication keys and host keys.

As well, would /keygen be updated to do conversions including adding an OpenSSH certificate (like I can now do in PuTTYgen), so that the work can be scripted?

Thanks!

Hi Martin,

indeed there are exciting changes! I have tried the new PuTTY with Kinetic Kudo and OpenSSH 9.x for the new "sntrup761x25519-sha512@openssh.com". It is a crypto nerd's fantasy, but I am excited to have it deployed soon in WinSCP too!

Many good important changes:
Support for OpenSSH certificates, for both user authentication keys and host keys.
Support for NTRU Prime post-quantum key exchange,
Support for AES-GCM (in the OpenSSH style rather than RFC 5647).

I know there won't be a quantum computer that can break >2048 bit key exchanges in the near future, but libraries/dependencies being up to date is good.

Just really excited ;)
Thanks for your work as always, sir!

We will definitely update WinSCP to PuTTY 0.78.
Is there any specific new feature of PuTTY 0.78 you are after?

Currently this should be 0.78, released on 2022-10-29.