Forum » Support and Bug Reports »

PuTTY is outdated

Advertisement

Advertisement

martin◆
Site Admin
martin avatar
Joined:
Posts:
42,194
Location:
Prague, Czechia

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?

Reply with quote

MarvinG
Guest

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!

Reply with quote

dr1818
Donor
Joined:
Posts:
24

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!

Reply with quote

Advertisement

martin◆
Site Admin
martin avatar

Re: PuTTY is outdated

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

Reply with quote

Advertisement

dr1818
Donor

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!

Reply with quote

Advertisement

dr1818
Donor
Joined:
Posts:
24

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

Reply with quote

martin◆
Site Admin
martin avatar

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

Reply with quote

dr1818
Donor
Joined:
Posts:
24

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

Reply with quote

Advertisement

dr1818
Donor

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

Reply with quote

martin◆
Site Admin
martin avatar

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

You can mark the attachment as private.

Reply with quote

Advertisement

martin◆
Site Admin
martin avatar
Joined:
Posts:
42,194
Location:
Prague, Czechia

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.

Reply with quote

dr1818
Donor
Joined:
Posts:
24

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!

Reply with quote

Advertisement

dr1818
Donor
Joined:
Posts:
24

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

Reply with quote

martin◆
Site Admin
martin avatar

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

Reply with quote

dr1818
Donor
Joined:
Posts:
24

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!

Reply with quote

Advertisement

dr1818
Donor

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?

Reply with quote

martin◆
Site Admin
martin avatar

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?

Reply with quote

dr1818
Donor
Joined:
Posts:
24

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!

Reply with quote

martin◆
Site Admin
martin avatar
Joined:
Posts:
42,194
Location:
Prague, Czechia

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.

Reply with quote

Advertisement

dr1818
Donor
Joined:
Posts:
24

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!
  • azure-scp-test_both_in_cert_and_seperate.log (13.31 KB, Private file)
Description: cert in key + standalone
  • azure-scp-test_cert_only_in_key.log (10.23 KB, Private file)
Description: Cert only in key

Reply with quote

martin◆
Site Admin
martin avatar

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

Reply with quote

dr1818
Donor
Joined:
Posts:
24

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!
  • id_rsa.pub-aadcert_pub.txt (1.99 KB, Private file)
Description: Renamed User cert.
  • puttyvm_redacted_ppk.txt (2.07 KB, Private file)
Description: Renamed ppk, with private key removed.

Reply with quote

Advertisement

dr1818
Donor
Joined:
Posts:
24

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

Reply with quote

martin◆
Site Admin
martin avatar

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

Reply with quote

dr1818
Donor
Joined:
Posts:
24

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!

Reply with quote

Advertisement

dr1818
Donor
Joined:
Posts:
24

The fix for servers using OpenSSH 7.x is in the PuTTY 0.79 pre-release
<invalid hyperlink removed by admin>

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!

Reply with quote

Advertisement

dr1818
Donor
Joined:
Posts:
24

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.

Reply with quote

martin◆
Site Admin
martin avatar

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.

Reply with quote

dr1818
Donor
Joined:
Posts:
24

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

Reply with quote

Advertisement

Advertisement

You can post new topics in this forum

Documentation

Support

Associations

Follow Us