With a basic SSH setup, you have to enter your password every time you log in to the server, which is not unreasonable from a security perspective. But if you want to automate tasks and use deployment tools such as Capistrano, you’ll end up typing that password over and over again, even for a single deployment process. Fortunately, there is a mechanism to avoid this while still preserving good security. But, as with most such things in Windows, it takes a little effort to set it up. (Things are a little simple on Macs, which we’ll cover in a future article.)

SSH authentication uses public key cryptography, in which you have a private key available only to you on your local system, and a matching public key that can be published on your server. Authentication software can confirm that the public and private keys match, but hackers cannot derive your private key from your public key. Once you set up a public-private key pair, these keys can be used to authenticate your SSH sessions, and you won’t ever have to type your password again.

There’s a couple different programs you can use to accomplish this; I’m going to explain how to do it with PuTTY and its associated programs, PuTTYgen and Pageant. If you installed the full PuTTY package, you’ll have all three programs already installed. If not, download the installer and run it now. (Be sure to get the full package, under the heading “A Windows installer for everything except PuTTYtel,” and not just putty.exe.)

Creating Your Keys with PuTTYgen

To create your public-private key pair, run PuTTYgen. There’s several types of keys, but SSH-2 RSA is the most common and is selected by default. (If this doesn’t work, you’ll need to check with your host to see what type of key their SSH server is expecting.) The number of bits defaults to 1024, which is fine. So all you have to do in the PuTTYgen window is click the Generate button, and then wiggle the mouse around a bit. The mouse movements generate random data that ensures that your key is unique.

When PuTTYgen is done creating the key, it will show a long string of characters that make up the public key. Select this text and paste it into a file, named something like id.pub (using notepad or any simple text editor). I made a folder at the root level of my C drive called SSH to store these keys and other related info, but you can put it anywhere you can find it later. (Note: you can also click the Save Public Key button and enter a file name, but this file won’t work as an alternative to the id.pub file we generated with cut-and-paste. It includes line break characters that confuse the server-side SSH code.)

Now you need to save your private key. If you just click the Save Private Key button, PuTTYgen will ask if you really want to save it without a passphrase, because we didn’t enter one. Here you have a choice to make between convenience and security.

The passphrase is essentially a password for accessing the key. Once you have your public key uploaded to your server (which we’ll do shortly), anyone who has access to your private key will have access to your server. If you use password protection on your PC, and you’re the only one with access to it, you might be comfortable going without a passphrase. But it is safest to use a passphrase, and we’ll soon see how you can make it so you only need to enter it once each time you boot your system. So to set a passphrase and save the private key:

• Enter it twice, once in the Key Passphrase field and once in the Confirm Passphrase field. Keep in mind that this passphrase is essentially the key to accessing your server, so make it a robust password.
• Click the Save Private Key button, and enter a file name (no extension) for your private key. The .ppk extension is automatically appended.

You now have your key pair and are done with PuTTYgen. Next you need to upload your public key to your server and set up your PC to access your private key.

Uploading Your Public Key

The details of uploading your public key may vary depending on the server configuration. The instructions below are for Rails Machine and are derived from the Mac and Linux oriented instructions they provide.

Open an SSH session to your server (using PuTTy, or another client if you prefer, as described in my previous post.) You probably have more than one user account; in my case, following the recommended practices from the Rails Machine folks, I have a root account that I never log into directly, and regular user accounts of Michael and Deploy. The Deploy account is the one I use for almost all communication with the server. So log into that account, or its equivalent for your setup. You’ll have to manually enter the password one last time.

Now, in the shell window that is connected to your server, create a directory for the private key file:

mkdir ~/.ssh

This creates a directory named .ssh within your home directory, which is where the SSH server will look for the public key.

Now set the permissions for this directory so you, but only you, have all privileges:

chmod 700 ~/.ssh

Now you have a directory on your server to hold your public key, and you need to move the key up there. There’s various tools you can use to do this. One tool you should become comfortable with is scp, or secure copy. It is not built in to Windows, but there is a version of it that comes with PuTTY, called pscp. If you add the path to the PuTTY program directory to your system path, you’ll be able to use pscp in any command window. (You may also want to install a set of Unix-style utilities; you can install the entire Cygwin environment, or if you want something lighter weight just for SSH-related tasks, get just the OpenSSH utilities. In either case, make sure to add to your Windows system path the folder in which these programs are stored, so you can use them from any command window without having to type their full path.)

To copy the public key, follow these steps:

• Open a Windows shell in the folder in which you’ve stored your public key. (If you installed the Command Here utility as I recommended in the previous article, you can just right-click the folder and choose Open Command Window Here.)

• In the command window, type

pscp id.pub username@hostname.com:~/.ssh/authorized_keys

(Of course, you’ll need to replace “username” with your actual user name, and “hostname.com” with the name of your server. If you’ve named your public key something other than id.pub, replace that name as well. Finally, if you’re using scp from OpenSSH instead of PuTTY’s pscp, drop the p in the command name.) This will copy your public key to a file called authorized_keys in the .ssh directory in your home directory.

Finally, to make the key file a little more secure, go back to your SSH window (remember, we started there but then switched to the Windows console), and type:

chmod 600 ~/.ssh/authorized_keys

This ensures that only the owner of this file (that’s the user name you began your SSH session with) can read or write it.

Making Your Private Key Available in Windows

OK, we’re almost there. Now we need to enable Windows programs making SSH connections to access your private key file. You could set PuTTY to use the key file, but that doesn’t buy you much, since it will ask for the passphrase every time you open a connection, and it won’t be available to other programs (such as Capistrano). So, you need to use another program called Pageant, which is installed along with PuTTY, to load the key into memory and make it available to other programs.

You can run Pageant directly via Start > All Programs > PuTTY > Pageant, and then you can tell Pageant to load your private key. But assuming you want the private key to always be available, you want it to load automatically upon startup. To do so, create a text file called load_private_key.bat (or whatever), with the following contents:

start “Pageant” “c:/Program Files/PuTTY/Pageant.exe” c:/ssh/id.ppk

Note that you’ll need to change the path to Pageant.exe if you didn’t install PuTTY in its default location. The id.ppk file is the private key file that you generated from PuTTYgen. (Using the “start” command, rather than simply providing the path to Pageant directly, prevents a DOS window from being left on the screen. Thanks to Tim Jervis for this tip.)

Finally, add this batch file to your startup tasks (Click Startup > All Programs > right click on Startup and choose Open, then right-click the load_private_key.bat file, drag it into the startup folder, and choose Create Shortcut from the menu that appears when you release the mouse).

Now, when you reboot your system, the batch file will run, Pageant will load your private key, and you’ll be prompted for the passphrase that you specified when you created the key. Enter this passphrase just this once, and your private key is now available to all SSH functions. When you shut your computer down, everything is secure again.

Setting up Subversion

If you’re using Subversion, you need to take one more step to enable it to use the private key generated by PuTTYgen: adding a line to Subversion’s configuration file.

Subversion’s configuration file is located in the Application Data directory under your user account. The full path is:

C:\Documents and Settings\{your windows user name}\Application Data\Subversion\config

Note that Application Data is a hidden folder, so to locate this file you must have Windows set to show hidden files and folders.

Open the config file in any plain text editor (such as Notepad) and add the following line:

ssh = $SVN_SSH plink.exe

plink.exe is the command-line link setup program that is included with PuTTY.

You’ll also need to make sure that the PuTTY directory is listed in your system’s Path.

Unfortunately, plink insists on popping up a DOS window, which is annoying. If anyone knows how to stop it from doing this, please let me know!

You’re Done!

That was simple, wasn’t it? :-) This may seem like a lot of trouble to go to just to avoid having to type your password, but once you’ve set this up once, you’re done. And if you’re using an automated deployment tool such as Capistrano, you’d have to type your password multiple times for a single deployment (since one deployment involved multiple SSH commands and other actions); with this setup, it can be fully automated.