SSH with public/private key on Windows -

[ergophobe]

I am having a lot of trouble getting ssh to work from a Windows XP machine to a server using public/private key authentication

I can

- connect to the server from the shell on another *nix box using public/private key authentication.

- connect to the server from Windows XP using keyboard interactive authentication

But when I try to connect from XP using pub/priv keys, I get this for debug output (SSH using the -vvv option).

debug1: Connecting to hostname.com [12.34.56.789] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Not a RSA1 key file c:/path/to/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
[... many times ....]
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file c:/path/to/.ssh/id_rsa type 1
debug1: identity file c:/path/to/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
...
debug1: Host 'hostname.com' is known and matches the RSA host key.
debug1: Found key in /cygdrive/c/path/to/.ssh/known_hosts:1
debug2: bits set: 507/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: C:\\path\\to\\.ssh\\id_rsa2 (0x610110)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: C:\\path\\to\\.ssh\\id_rsa2
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply

I've tried this with keys generated on the Windows box, keys generated on the target server, and the keys that are actually working, generated on a second server and allowing that box to connect to the target server using those same keys. Yet when I try it from Windows (including two different versions of OpenSSH) no dice.

And by the way, my main goal is to be able to access git repositories, so I don't think switching to PuTTY or some such is helpful. AFAIK git for Win uses the OpenSSH version that's packaged in with it.

[Dijkgraaf]

It sounds like you have a PKCS #10 or a PEM formated SSH key. Windows server supports the following formats PKCS #12 (.PFX or .P12) or a PKCS # 7 (.P7B)
So what you need to do is either save your key in one of the above format or on your unix box run the following command (substituting the appropriate file names)
openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer
This information comes from the following page which goes into detail on the different formats.
[sslshopper.com ]

[ergophobe]

Thanks!

These are RSA keys, though, not SSL certs.

There's no Windows Server anywhere in the equation - it's two linux boxes (CentOS) and a Windows XP machine. I can use either linux box as client or server and connect either direction, but I can't connect to either one using the Windows box as a client.

[Dijkgraaf]

You still need to get the key in a format that window understands however.
Try saving the cert as OpenSSH key.
I've use PuTTy Key Generator [chiark.greenend.org.uk...] to convert a SSH-1 (RSA) to OpenSSH key to get it to work on a Windows Box.

[ergophobe]

Okay... didn't get back to this because the problem machine decided to just die entirely. Black screen. No boot. So we'll see how this goes when its replacement machine comes in. Thanks though.