Windows-to-linux: Putty with SSH and private/public key pair

Question

I spent about 3 hours trying to figure out how to connect to a linux box from my windows machine using putty without having to send the password.

This is connecting to an Ubuntu server that is using OpenSSH. The private key is SSH-2 RSA, 1024 bits. I am connecting using SSH2.

I have run into the more common problems already:

1. Putty generated the public key in the "wrong format". I have corrected this (as seen on this blog post). However, since I am not yet connected, I cannot absolutely confirm that this file is in the correct format. The key is all on a single line now, and I have tried adding/removing line breaks at the end of the file. I've also tried the public file doctoring process a few times to ensure that I haven't flubbed up the manual conversion. Even so, I have no way to verify accuracy here.
2. The permissions were at once point wrong as well, specifically meaning that the file had too many permissions. I had to solve this too and I know it got past this because I no longer see a related error in /var/log/auth.log.
3. I've tried both authorized_keys and authorized_keys2 in case the server has an old version of OpenSSH, but this changed nothing.
4. I do have access as a user. After this keyfile stuff fails, I can enter my password instead

The only remaining nibble of information I have is that it claims I have the alleged password wrong:

sshd[22288]: Failed password for zzzzzzz from zz.zz.zz.zz port 53620 ssh2

Even so, as far as I can tell, this is just a lazy try/catch somewhere, since I don't think there's a password involved at all.

I see nothing else in any of the /var/log files of use. What else could be wrong?

Solution 1

• Generate your key with PuttyGen.
• Right-click in the 'Public key for pasting...' text box and choose select all
• Right-click again and choose copy.
• Connect to your host and edit .ssh/authorized_keys, and paste in your key, remove any other pre-existing stuff from when you tried following that video.
• Verify that your ~/.ssh folder is 0700 with chmod 0700 ~/.ssh/
• Your authorized_keys file should be 0600 so chmod 0600 ~/.ssh/authorized_keys.

Solution 2

Generate a keypair and store the public key on the server as suggested by @Zoredache. Enter a password for protecting the private key and click Save private key and save the key e.g. in your user profile. Remove permission for everyone except yourself from the key file.

To be able to authenticate with your private key, you need to make it available to PuTTY. Either load it with Pageant or enter it in the PuTTY configuration dialog under Connection > SSH > Auth (click Browse... and choose the file you just saved).

In the same dialog, category Session enter the hostname or IP address of the host you want to connect to in the respective field. Switch to the sub-category Logging and click All session output, then click Open.

When the terminal window opens, right-click on the title bar and select Event Log. This client-side log complements auth.log on the server side and should help you find out what's going on.

Solution 3

that means the key exchange did not take place or failed.

please download the cli tool plink.exe (same place you downloaded putty.exe) and do some debugging

plink -v -i yourprivatekeyfile user@server

see what it tells you, in addition to what the server says.

you can do this in a powershell or cmd window.

if you have already generated your default putty public file, you can convert it with

ssh-keygen -i -f yourputtypubkeyfile > openssh.key

to be added to your authorized_keys

Comments

[Johnny Kauffman]

I had used plink -v and it certainly helped in diagnosis early on, but the last issue turned out to be a problem that could only be logged on the server-side. I'm pretty annoyed that the server-side logging let me down so badly. Without any available working examples of a public key to compare to, I was left to wonder whether or not I had truly gotten the formatting correct (I could have used an empty file and seen no difference). On top of that, the error log's "invalid password" claim was simply bogus. Perhaps there's a more verbose OpenSSH logging option? ...

[Johnny Kauffman]

Right you are. I screwed up the hard way (I left out ssh-rsa). Taking it form the textbox eliminates the human error. I hadn't even noticed that the format within that window was different than the generated public key.