(Updated: added tip on stopping pageant DOS window from popping up, and integrated formerly separate post on using Subversion)

In a previous post, I described how to set up SSH access from a Windows system to a remote Linux server. With this basic 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.

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 as recommended in my previous article, 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.

All the cool kids in the web world these days seem to be using Macs, which have hearts of Unix so are natural complements to Linux-based servers. Others are running Linux desktops. So a lot of the remote server administration information on the web assumes that you’re on either a Mac or a Linux box.

For historical reasons, however, I have a collection of Windows systems, and they’re what I’m comfortable with. I also have some things, like my collection of 60,000 photos managed in the Photoshop Elements Organizer, that aren’t easily moved to a Mac, and I have lots of Windows applications that I own and am familiar with. So while I don’t have any religious feelings about it (please, spare me the Mac evangelism), I’m using Windows systems to remotely administer my web servers.

This really isn’t a problem, as there are ample tools available to make Windows do most everything a Linux system does, or a least everything you need to do to administer one remotely. But it does take a little more effort, at times, to track down the right tools and figure out how to apply them. If you’re early in this process, this article may help. (If, on the other hand, you’re a grey-beard Linux hacker or a Mac die-hard, you can stop reading now.)

Although there are GUI interfaces for Linux, remote administration is done predominantly from the command line. And if you want to follow the well-greased paths for deploying Rails applications, you’re going to be living in a command-line world. This is, of course, rather alien in the Windows environment.

There’s really two command-line environments you need to use: the Windows command shell, for taking actions on your local machine, and a Linux shell, for interacting directly with your server. The Windows shell is essentially a grown-up version of the old DOS prompt. Linux shells come in a variety of versions, with BASH being the most common.

Enhancing the Windows Command Window

You need to use the Windows shell to control your local development environment, and with some extensions (to be described in a later post), you can use it for some tasks that involve your remote server as well.

To open a Windows command shell, you can select Run from Start menu and then enter cmd and click OK. But there’s a better way: Microsoft offers a free add-on that lets you open a command window by right-clicking on any folder and choosing a new option that the add-on installs, “Open Command Window Here.” Aside from being quicker than the Start > Run > cmd approach, it opens the command window with the current directory set to the folder upon which you right clicked. Download the command window PowerToy. It is entirely painless and will make your life just a little bit simpler.

Now you should customize your command window settings, as the defaults are pathetic. The window has no menu, so it may not be immediately clear how one customizes it. The secret is to open any command window, right-click on the title bar, and choose Properties. Once in the properties dialog, here’s some things you might want to change:

• In the Options tab, check the boxes to enable Quick Edit Mode and Insert Mode. This enables you to cut and paste text (you can’t use ctrl-X and ctrl-V like you can in a GUI environment). To copy, select the text and then click the right mouse button. To paste, just click the right mouse button.

• Also in the Options tab, change the Buffer Size to 999, and the Number of Buffers to 5. This gives you more memory for past commands. At any command prompt, press the up arrow repeatedly to move back through previous commands. This can save a lot of typing.

• In the Layout tab, increase the Screen Buffer Height to 2500, so you’ll have more text you can scroll back through after it scrolls off the top of the window. Increase the Screen Height to provide a window as tall as you’d like; I prefer 75 for my 1200-pixel-high monitors.

• In the Colors tab, change the text and background colors if you’d like. White text on a black background is traditional and has a retro appeal, but I prefer black text on a white background.

When you’re done making changes, click OK, and then choose Save Properties for Future Windows in the dialog that appears. Now you’ll have a much nicer command window to work with from now on.

Get Set up for SSH

Although you can use the Windows command prompt to act upon your remote server, the primary method used to access Linux systems remotely is SSH (Secure Shell). There’s not an SSH client built in to Windows, but good free clients are available. The most popular is PuTTY. Download the PuTTY installer package. Choose the download labeled “A Windows installer for everything except PuTTYtel”, which will get you the complete set of PuTTY utilities, some of which you’ll want later.

Run PuTTY, and you’ll see a deceptively simple window. There’s actually lots of options here, which you can explore by clicking the categories on the left. But you can get started by using all the defaults and simply entering the name of your host (or its IP address) in the Host Name field and clicking Open. (To save yourself a little typing in the future, you can enter a name under Saved Sessions and click Save, and then the next time you can just double-click this name in the Saved Sessions list.)

Assuming PuTTY is able to connect to your host, you’ll then see another of those lovely white text on a black background windows (you can change these settings in the initial PuTTY dialog), with a Login: prompt. At this prompt, enter the user name your host assigned you, and then you’ll get a password prompt. Enter the correct password, and you’ll be online talking to your server, with essentially all the control that a user sitting at the machine has. All data sent back and forth is securely encrypted, so no one will be able to sniff your network traffic and figure out how to get into your server (unlike FTP, in which not only your files but also your user name and password are sent in clear text).

If you aren’t able to connect to your server (even to the point of getting a Login prompt), then check the following:

• Make sure your host has enabled SSH access. If you have a shared hosting account, it might not be offered, or you might have to ask for it.

• Make sure you have the host name right. This should be simply the domain of your web site. If it is a new account and you haven’t set the DNS yet, you can use the IP address.

• If all else fails, check with your host to see if they’ve moved SSH to a port other than the standard 22. Some companies are doing this to reduce brute-force attacks. You can enter any port number in the PuTTY dialog.

If, on the other hand, you get the login prompt but it doesn’t accept your user name or password, double-check that you have these exactly correct. For some hosts, you may need to use “name@domain.com” and not just “name” for your login name. Check the signup material you received when you opened the hosting account.

Once you have these two command-line environments in place, you have the essential tools to both control your local development environment and to administer your server. Now you just need to know what to type into these windows :-). More on that in future posts…

For more information:

• Excellent overview of SSH software for Windows

• Windows Command Shell Overview

• Complete (though badly presented) Windows Command Reference

• A good third-party Windows command line reference