Tag Archives: ssh

Dealing with key-based authentication on Windows with Putty

I’m writing this entry because I’m going to be writing another entry soon, and I want to point to this rather than explain it in situ. 

Here lately, I’ve been using Windows on my desktop. At work, this is mostly because of the extensive administration I do with VMware, and there’s STILL no native way on Linux or Mac to do things like Update Manager, and at home, because I play lots of video games. Lots. Of. Games.

The end result is that I spend a lot of time using Putty. There are a lot of Windows-specific SSH clients, but I like Putty’s great combination of being tiny, running without any actual installation, and reasonably dense feature-set. If you’re on Windows and you need to deal with Linux hosts, you’re probably already using Putty, but maybe not as completely as you could be.

There is a small  ecosystem of applications that work with Putty, including sftp clients and an SSH client that runs in the Windows command prompt (plink). They’re all available on the same Putty download page. The biggest win, in my opinion, is to combine it with Pageant. Much like ssh-agent on Linux, Pageant manages your SSH keys, allowing you to log into remote hosts without typing passwords, and only typing your key’s passphrase once.

The first step with key-based authentication is to actually generate some keys. For Pageant, the easiest way is probably to use PuttyGen, which looks like this:

Click “Generate” and move the mouse around as the directions say:

This produces your actual key:


You want to type in a “Key passphrase” that is a long-ish phrase that you can remember well enough to re-type occasionally. Once you’ve done that, click “Save public key”, make a keys directory, and save it in there, then do the same with “Save private key”. You should care that people don’t get the private key, but your passphrase should be long enough that it’s unlikely that anyone could brute-force your key before you change it or lose it or maybe if you like typing, until the heat death of the universe.

Copy the text at the top and save that into notepad so we can have it after this closes. We can get it again by re-running the key generator, but if you’re like me, you didn’t install it, you just kind of ran it from your downloads, and you’d probably have to download it again to run it again, so just keep the text in Notepad for now.

Alright, so now you want to download Pageant and this time, you want to save it somewhere useful. I have a “Programs” directory that I made under C:\Users\msimmons\ that holds stuff like this, so I saved it there. Once it was there, I right clicked and said “Create Shortcut”, which I then dragged into C:\Users\msimmons\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup – this makes sure that Pageant will start when I log in. By default, that won’t actually load my key, though, so we have to edit the properties on the shortcut and add the key as an argument to the executable:


Now, when you log in, you’ll be prompted to type the passphrase to your private key, which will allow you to put that public key into the authorized_keys of a target host and authenticate as that user without typing a password every time! Excellent!

Guaranteeing scripts don’t get hung on remote ssh

This is probably remedial for a lot of you, but it never occurred to me before today.

I’ve got a lot of shell scripts that run in cron or manually, and a significant portion of those need to connect to a remote server via ssh, either to rsync or to issue commands, or whatever.

The way I do this is to set up key-based authentication between the machines…but what if, for whatever reason, that doesn’t work? Have you ever ran a script, and after 5 minutes, you realize it hasn’t finished, because it’s still sitting there yelling at you:

username@yourhost’s password:

That’s no fun…mostly because you’re probably going to end up typing the password another dozen times (or more!) for each time that it has to connect to a remote host to which you haven’t copied the keys.

Today, I learned and/or realized that you can specify options from ‘man ssh_config’ on the command line to ssh. That means you can avoid the mess above and more gracefully handle these exceptions. Instead of just

ssh user@remotehost command

Do this:

ssh -o PreferredAuthentications=publickey user@remotehost command

This causes the result to be

Permission denied (publickey).

Probably more importantly, it returns an error code (255 in this case), which you can handle in-script:

 if ! ssh -o PreferredAuthentications=publickey \
           $USERNAME@$HOST $COMMAND ; then
    echo "Sorry, key authentication failed for $HOST"
    exit 1

I’m not sure why it never occurred to me before, but it’s a great way to account for those oddities which seem to crop up from time to time.

By the way, if you’re unfamiliar with key-based authentication in SSH (or with SSH tricks in general), there are several posts from a few years back where some other bloggers and I covered various SSH tricks that you might be interested in.

Drop a comment and let me know how you handle these sorts of things. Your way is probably better than mine, and I’m interested in hearing about it!

What? SSH stuff AGAIN?!?!?

Apparently the SSH fiasco isn’t done. I didn’t believe it either, but there are still things that haven’t been covered!

Daniel, at Bonetree Blog wrote an overview of a great tool to have in your toolbox: SSH tunnels. Completely aside from the inherent security that an SSH tunnel provides, I’ve got lots of random hardware (usually cheap routers, APs, and the like) that only want to allow an administrator to log in if the admin is on the same subnet that they are. That’s a pain in the butt when you’re a couple of states away! To remedy this, I connect to a server that IS on the same network as the device and I create an SSH tunnel through the server to get to the appliance. Daniel explains it better than I’m doing, and he actually uses it to make a SOCKS proxy. Just read his article.