Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

dr1818

Thank you for the quick support and fix!
martin

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

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
martin

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.
dr1818

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.
dr1818

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

Thanks
martin

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

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!
dr1818

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!
martin

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

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
martin

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
dr1818

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!
martin

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)?
dr1818

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!
dr1818

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

Thanks
martin

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.
dr1818

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!
martin

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?
dr1818

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

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!
martin

@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?
dr1818

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
dr1818

Re: Beta 6.0.0.1 : Private key with OpenSSH cert works for SFTP, but not SCP

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!
martin

Re: Beta 6.0.0.1 : Private key with OpenSSH cert works for SFTP, but not SCP

@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.
dr1818

I uploaded the redacted SFTP log privately. Thanks!
martin

Re: Beta 6.0.0.1 : Private key with OpenSSH cert works for SFTP, but not SCP

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

Re: Beta 6.0.0.1 : Private key with OpenSSH cert works for SFTP, but not SCP

@martin: Done.
Thanks
martin

Re: Beta 6.0.0.1 : Private key with OpenSSH cert works for SFTP, but not SCP

You can mark the attachment as private.
dr1818

Re: Beta 6.0.0.1 : Private key with OpenSSH cert works for SFTP, but not SCP

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

Thanks
martin

Re: Beta 6.0.0.1 : Private key with OpenSSH cert works for SFTP, but not SCP

Please attach complete logs.
dr1818

Beta 6.0.0.1 : Private key with OpenSSH cert works for SFTP, but not SCP

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:
. 2023-03-15 21:52:59.692 Looking for network events
. 2023-03-15 21:52:59.692 Server offered these authentication methods: publickey
. 2023-03-15 21:52:59.692 Offered public key

For SFTP which succeeds
. 2023-03-15 21:54:12.169 Looking for network events
. 2023-03-15 21:54:12.169 Server offered these authentication methods: publickey
. 2023-03-15 21:54:12.169 Sending public key with certificate from "C:\Users\scrubbeduser\.ssh\scrubbedpath\id_rsa_scrubbedfilename.pub"
. 2023-03-15 21:54:12.169 Offered public key

Thanks
martin

@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.
dr1818

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
martin

Re: PuTTY is outdated

@dr1818: Thanks for your feedback.
dr1818

Re: PuTTY is outdated

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!
martin

@hlfritz: Probably within two weeks.
hlfritz

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

Thx!
martin

Re: PuTTY is outdated

@dr1818: Thanks for your feedback.
dr1818

Re: PuTTY is outdated

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

Thanks
martin

Re: PuTTY is outdated

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

Re: PuTTY is outdated

Thanks from me as well!
dr1818

Re: PuTTY is outdated

Thank you!
martin

Re: PuTTY is outdated

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
dr1818

PuTTY 0.78 support/ OpenSSH certificates

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!
MarvinG

Re: PuTTY is outdated

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!
martin

Re: PuTTY is outdated

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

PuTTY is outdated

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