Most system administrators soon find that working at the command line is the best way to work, for several reasons:

  • Low bandwidth
  • Ubiquity
  • Scripting

In this article, I'll describe ways to make use of SSH for fast, easy access to multiple systems with good security. Instructions are provided for both Windows and Linux clients.

Setting Up PuTTY on a Windows Workstation

First, get PuTTY. You can download it from in the form of a zip file or as a Windows installer. At the time of writing, the latest release is version 0.60, and that is what was used in the screenshots.
You can install PuTTY by running the installer, or by unzipping the zip file to C:\Program FIles\putty.

Connecting to a Remote Server

Start PuTTY from the Start Menu, a desktop icon or by using Start -> Run....

To set up a session, first insert the host name, and make sure the Port number is set to 22 and Connection type is SSH. Click on Window - Appearance and change the font if required for clarity. Now click on Connection. If your connection will be passing through a masquerading firewall (which performs network address translation and may time out, breaking the connection) you should enable sending of null packets at (say) 60-second intervals.

Click on "Data" and enter your username; this can be an ordinary user account name or can be "root" for system administration purposes.

Click on "SSH" and check "2 only" as the SSH protocol. This will disable fallback to the version 1 protocol. If using a slow WAN connection, check "Enable compression".

PuTTY Configuration
Expand the SSH options and click on "Auth". Ensure that "Attempt authentication using Pageant" is enabled, and check "Allow agent forwarding". If you do not intend to use Pageant, use the "Browse..." button to select a private key file, if you have one (see below).

If you have an X server, select the X11 page and check "Enable X11 forwarding".

Once everything is set up, you should click on the "Session" page link, give the session a name in the "Saved Sessions" text box and click the "Save" button.

Now, test the session setup by clicking on the "Open" button. A text window should appear and you will be prompted for your password on the remote system (assuming you have not previously set up key-based authentication).

Generating Keys

Start the PuTTYgen program from the Start Menu, or use Start -> Run.... Make sure that "SSH-2 RSA" is selected in the Parameters box, and increase the number of bits in the key to 2048 if you're paranoid, then click on "Generate". Move the mouse around over the blank area to provide randomness. The result should look like this:

Type in a long and complicated passphrase which will be used to protect the private key, then click on "Save private key". Give the key a semi-descriptive name, but be careful not to leak any information that might reveal what the key is used for or what the passphrase is. Store it in a folder (directory, really) under "My Documents" - I use one called  "My Keys" and/or put it on a USB key device.

There is no real point to saving the public key - it's not compatible with OpenSSH anyway. Furthermore, the PuTTY .ppk file contains both the private key and the public key, so you can get back the public key by simply loading the .ppk file into PuTTYgen.

Keep the PuTTYgen window open while you move on to the next step.

Installing the Public Key on a Remote Server

In order to enable authentication via keys rather than passwords, you will have to upload your public key onto servers you will log in to. Here's how to do that:
First, create a session and log in using your password. Now, give the following commands:

mkdir .ssh
chmod 700 .ssh
cd .ssh
vi authorized_keys

Now go back to the PuTTYgen window and select all the text in the "Public key for pasting into OpenSSH authorized_keys file" text box, then press Ctrl+C to copy it. Put your mouse over the PuTTY session window and right-click. This should paste the key into the vi editor session. Continue with the following:

chmod 600 authorized_keys

You can now log out.

Eliminating Passwords

You can now specify the private key file in PuTTY session configurations (Connection/SSH/Auth), but every time that you start a session you will be prompted for the passphrase which protects the key (NOT your password on the remote system). This is somewhat tedious.

A better approach is to set up an authentication agent to provide keys automatically for each session.  Here are the steps to do this:

First, in the Windows "Start" Menu, choose "All Programs", navigate to "Startup" then right-click on it and choose "Open...". This will open up the Startup menu folder (C:\Documents and Settings\username\Start Menu\Programs\Startup). Right click in the background of this folder and choose New -> Shortcut. The "Create Shortcut" dialog will appear. Click on the "Browse..." button and navigate to C:\Program Files\PuTTY\pageant.exe (or type this straight into the location field). Click on "Next >" and click on "Finish". Double-click on the "Shortcut to pageant" icon you have just created, in order to start it.

You should see the Pageant icon - a terminal with a hat on top - in the Systray at the bottom right of your display. Right-click on it and choose "Add Key". Navigate to the location where you saved the private key (.ppk) file earlier, and open it, providing the correct passphrase when prompted. Now right-click again on the Pageant icon in the systray, and choose "Saved Sessions". You should see any sessions you have previously created, and when you select one, you should connect immediately with no prompting for a password.

As long as the agent holds your key(s) you can connect to systems without being prompted for the key passphrases. Of course, there is a small security downside - anyone who sits at your machine can now initiate sessions without knowing your passwords. So:

Make sure that when you leave your Windows workstation you lock the computer (Ctrl+Alt+Del, then click on "Lock Computer", or press Windows+L).

Alternatively, you can select "View Keys" on the Pageant pop-up menu and remove the keys.

Setting Up OpenSSH on a Linux Workstation

Most Linux distributions have OpenSSH installed by default, with the server enabled. When the system starts sshd for the first time, the start/stop script usually generates keys for the various algorithms automatically.

Connecting to a Remote Server

The basic syntax of the ssh command is:

ssh [-l username] hostname [command]

If you have the same username on a remote host, then connecting is as easy as typing:

ssh hostname

The -l option lets you specify a different username if you want (you can automate this with the ~/.ssh/config file, described below).

If you have previously uploaded a private key, you should be logged in immediately; if you have not, you will be prompted for a passphrase.

Generating Keys

To generate a 2048-bit RSA 2 key, use the command:

ssh-keygen -t rsa -b 2048

and follow the prompts. The command will generate a private & public key pair, stored in the files id_rsa and respectively in your .ssh directory. Make sure that you use a long and complicated passphrase to protect your private key.

Installing the Public Key on a Remote Server

In order to enable authentication via keys rather than passwords, you will have to upload your public key onto servers you will log in to. Here's how to do that:
First, log in to the remote system at the command line, using a password, to check that you have connectivity. Now, on the local system, give the commands:

cd .ssh
scp [username@]hostname:

This will copy your public key to your home directory on the remote machine. Note the colon (:) after the hostname. Now, in your remote session on that system, give the commands:

cd .ssh
vi authorized_keys

Once vi has started, read in the public key with the vi command:

:r ~/

and save the file with the command


Finally, set the permissions on this file so that only you can access it:

chmod 600 authorized_keys

Automating the Supply of Keys

Linux distributions which run a desktop environment such as GNOME and KDE usually have an integrated SSH key agent. If you are working at the desktop, open a command line and give the command:


You should be prompted for the passphrases for any keys which the agent discovers in your ~/.ssh directory. From this point on, you should be able to ssh into remote systems without being prompted for the key passphrases.

If you leave your workstation, make sure that you either lock the desktop or remove all keys from the agent with the command

ssh-add -D

The SSH agent is automatically invoked by the graphical desktops, but you can use it from the command line, e.g. on server or other non-graphical machines. Use the command

ssh-agent $SHELL

to invoke a new shell as a child of the SSH agent. Now you can use the ssh-add command, as above.

Disabling Password Authentication

On Internet-facing hosts, I prefer to disable password authentication altogether. Edit the file /etc/ssh/sshd_config and at the end, add the line

PasswordAuthentication no

Changing Your Username, Automatically

If you have a different username on a remote host, you can use the OpenSSH config file to provide the correct username by default. Just edit ~/.ssh/config and add a section for the host. For example:

Host midgard
  User lbell

Now, the command ssh midgard will automatically connect me to the server and log me in under the name lbell. This is particularly useful when you want to connect to machines that are not in your current domain or domain search path, and particularly for administrators who will often want to log in as root.

Remote X

The administration utilities for many Linux distributions are now primarily graphical, e.g. the system-config-* scripts on Red Hat Enterprise Linux. You can run these remotely if you have an X server running - e.g. on a desktop Linux workstation or if you have an X server such as Hummingbird Exceed on a Windows workstation. Just make sure that the /etc/ssh/sshd_config file has the line:

X11Forwarding yes

Many Linux distributions have this set to no by default.

Disable Protocol Version 1

There are weaknesses in Version 1 of the SSH protocol. You should disable support for version 1 on your servers: find the line in /etc/ssh/sshd_config that reads:

Protocol 2,1

and edit it to read:

Protocol 2

This will prevent the server from "falling back" to the SSH 1 protocol. After making any changes to the server configuration, you should restart it (e.g. with the command service sshd restart.