"Unable to load private key (createkey failed)" message in 0.71

[y***@gmail.com]

Hi,
I have a .net application that creates a .ppk file from an RSA key pair. I can use this file to authenticate with a server running OpenSSH 6.7p1 with versions other than 0.71. In 0.71, I get the message in the subject line. Any ideas what could be causing this?

[Simon Tatham]

Post by y***@gmail.com
I have a .net application that creates a .ppk file from an RSA key pair.
I can use this file to authenticate with a server running OpenSSH 6.7p1
with versions other than 0.71. In 0.71, I get the message in the subject
line. Any ideas what could be causing this?

It's likely that your .ppk file is subtly misformatted in some way
that 0.71 is checking more carefully than previous versions of PuTTY.
But it's impossible to say in what way, unless you provide an example
file.

(It need not contain a live key, of course! Generate a fresh test key
and check that it provokes the failure.)

[y***@gmail.com]

Post by Simon Tatham

Post by y***@gmail.com
I have a .net application that creates a .ppk file from an RSA key pair.
I can use this file to authenticate with a server running OpenSSH 6.7p1
with versions other than 0.71. In 0.71, I get the message in the subject
line. Any ideas what could be causing this?

It's likely that your .ppk file is subtly misformatted in some way
that 0.71 is checking more carefully than previous versions of PuTTY.
But it's impossible to say in what way, unless you provide an example
file.
(It need not contain a live key, of course! Generate a fresh test key
and check that it provokes the failure.)
--
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,

Here's the contents of a sample file:

PuTTY-User-Key-File-2: ssh-rsa
Encryption: none
Comment: imported-key
Public-Lines: 6
AAAAB3NzaC1yc2EAAAAEAAEAAQAAAQEA35GnCBwtPKHOb6yBxZuuL1kqh9J5deSc
vLCHBru6rh1XUj1yLliqN+uRgQNgw4eWutadyPQkJ2iLZLeno1DmjTcdh/AZ9H/g
BnyYbl24p+wdBpx3TOSQdrFx4HEgi1GwAAUvd1rbsz8GoNTKAA6BfyBg37qx0C4B
D20H7mh29dnBlPqYwiEE1sObmaqTTUIQeVXWDCMBLyKoJw77m/PP5mAQfqG0iEtX
uHycZ+ErrPFWm4HxXaU0uoLzr1DOUoSqn+sGu+5HEXZkiyvHC6Pupp3lEl15zndU
HBTWe2uFPppee2zMh75Hptk70VPJbpT41m1CMv817erzt4kv2WBExw==
Private-Lines: 14
AAABAQAcVVziJegEbMvj0pdTut+ADVXa3Bgb59AxXac5zuWMFsMv9Kzu0Lp/LHHx
SW35pHURfWIxII0gbXBqYELKQNYnLsVQVWPaB7Fq67QfG0OWtya/5Wkn1o5fFy1D
xjKGADaaRLiiRg0yke8+HMRI7jhdKyD72bDv8unxfDOVdFR3OFgBVulpmqUGJ2tJ
gSHSsAK4LL7cuf1/g2EiMOCo8a8pzJxlc3bmhHRWokwUJoJO4zjKevfmqruo5F4p
ywKJYjgbs9Ex1MfqFa1eKtwORkdgEKS+dz83VANOyc9pc65t0YFwQ05eYZyRENie
62yBJw15M0GCXwF+kijtDbE+LkYxAAAAgQD1aFoaVrZO5G+Hjdsy4KpAjwukuIbc
+rB2z077Hpsec8enGMbkxWx0Jltbmu8VVuL9D9EnwFzlaHaNLoirYttyPSX4cTy3
XSwRRNGB7iksdGnkogTZJ8xHUjAeyVjGVWPbSGEBWE9zZEYzQ544IJFxsthCysDm
3xzSO5cK4HGXHwAAAIEA6Tf+HoFRyXP7/Bl7dTl8BLfpa3FmLMSq4so2qYZYo3Md
s7VmtArPLyzehXgdYOS3Xmocp2mv1549ii4ZxlAu+/n543MFLg2Qe8e3mnfkQ5E/
k4UHPE5/vDmmzLK1FJJGgvsCOCQ+ujRfghU70QxQcO3I6/Wj7ybbdigkNhfM5VkA
AACBAAKoAbuDtTUhWIbRGBmYga17PWfa3ZeBFv/3VeAZ3PfdE6/IEi9YqR/myQpp
YsVXyzNW5CHWmkQrm7ngUEckz20iQ8xCoiQkPwJYcWukU2n1C8XOZKeKKvp+hbJX
1aS2cE1oDfz10WElhQF+VasUdnstahwO7wIsd6BlAT6h4Bmp
Private-MAC: 2edab8a0d4841833fb755dfd78d93b9b9d44ce70

[Simon Tatham]

In the public blob, the exponent of the RSA key is represented by the
byte sequence

00 00 00 04 00 01 00 01

i.e. a length field indicating that 4 bytes of the number follow, and
then the actual number is given with a leading zero byte.

That's the wrong representation. PuTTY's key file encoding follows the
normal SSH convention for an mp-int: a leading zero byte should only
be included if the topmost bit of the next byte is set. An exponent of
0x10001 should be encoded as

00 00 00 03 01 00 01

(However, the leading zero byte on the _modulus_, immediately
following that mis-encoded exponent, is correct, because the next byte
is 0xDF.)

Similarly, your private blob has a leading zero byte on every integer
it includes, regardless of the value of the following nonzero byte.