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

icenv

After reviewing the script, I found the origin of the problem was the implementation (PHP side) of PuTTY's BinarySink_put_mp_ssh2_from_string (import.c) function, that adds a leading zero only in certain circumstances before a binary string, whereas our script was always adding it.

I can confirm after fixing that, that I can connect to the same server with the new key with WinSCP 5.17.1 and the latest PuTTY 0.73.

I don't know how to edit the topic subject, but this is resolved. (Why older PuTTY code did tolerate these keys remains a mystery though.)
icenv

Yes, there seems to be a problem with padding the keys.

Your previous comment about the keys being the problem prompted me to try this :

Using an older PuTTY version that is able to load the keys, I loaded the server key, and saved it again using PuTTYGen ;
Then using a diff tool I saw the base64 private portion of the key is different ;
Now I'm using a hex editor to se the difference, it seems that there are two NULL bytes improperly placed in the file.
I'll update the topic if I'm able to resolve this.

Anyway thanks again for pointing me in the (hopefully) right direction!
martin

I indeed cannot even load your private key to PuTTYgen 0.73.
The latest development build of PuTTYgen does even hang while trying to load the key.
icenv

Hi, Thanks for taking the time to reply.

I tried doing so, however as you can see, the session log doesnt rally show why createkey failed, only that it did; I attached the same logs with 5.15.9.
I did put the logs at their maximum verbosity level.

We generate our keys via PHP/OpenSSH and then convert them to the PuTTY format all with a PHP script, because it's an automated remote process. I'm starting to wonder if indeed our keys are the problem. I attached a keypair I just generated with the same script for testing purposes.

Thanks again!
martin

Re: Regression : cannot use 3072-bit RSA key for authentication

Thanks for your report.
I cannot reproduce the problem. I can authenticate with 3072-bit RSA key without any problems.

Please attach a full session log file showing the problem (using the latest version of WinSCP).

To generate the session log file, enable logging, log in to your server and do the operation and only the operation that causes the error. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.


How do you generate the key? Also can you generate a new key with the same parameters and post it here?
icenv

Regression : cannot use 3072-bit RSA key for authentication

Problem version : 5.17.1 (upgraded from 5.15.9)
Last working version : 5.15.9
OS Version : Windows 10 x64
UI mode : commander
Configuration :
remote server only uses AES for encryption, curve X25519 for key exchange.
private/public key pair is RSA, 3072-bit.
Steps to reproduce :
Open WinSCP, type in the IP and username, go to Advanced->ssh->authentication, select key file (ppk), click connect
Expected result :
Successful connection, as in 5.15.9 and below, with the exact same server and keypair.
Actual result :
Error message that winSCP cannot authenticate "cannot create key".

If WinSCP uses a PuTTY library, it is entirely possible that the bug comes from PuTTY, because we also had to downgrade it, as our keys were also causing problems on latest versions. However, this is only speculation.

Thanks in advance for any help/resolution , in the meantime we downgraded back to 5.15.9