SSH Key Exchange: Windows client to Unix/Linux server
Audience
Windows users who wish to exchange SSH keys with one or more Unix or Linux servers.
Purpose
To implement public-key login onto one or more Unix or Linux servers from a Windows box (e.g., to allow password- free CVS access from an Eclipse IDE).
For public-key login to work, the server's SSH public key must reside in the appropriate directory on the workstation from which login is attempted; while the user's SSH public key resides in the appropriate place on the server. These instructions explain how to tell if this is already done for the workstation-server pair of concern; and, if not, how to effect appropriate exchange of public keys.
Prerequisites
These are the basics; if your machine isn't running these, please install or upgrade as appropriate:
- Operating System: Upgrade to latest stable, high-encryption releases of Windows
- SSH Secure Shell: Install on your box; if you already have it installed, be sure the version is recent. For UCB community members, IS&T-WSSG maintains the currently licensed version of SSH for download (v 3.2.9 as of 01.24.2005). Note: These instructions presume that the installation directory for SSH is C:\Program Files\SSH Communications Security\SSH Secure Shell\. If your installation directory is different, translate these instructions accordingly.
SSH Key exchange: Windows client & Unix/Linux Server
Following these instructions in the order presented should result in successful SSH key exchange. Success in this effort is dependent on careful attention to detail; failure is often the result of inattention to permissions in the user's home directory tree on the server to which public-key login is desired.
It is of key importance throughout this procedure to use consistent references to the server:
- It may seem obvious, but myserver is not the same as myserver.berkeley.edu; ditto for mybox and mybox.berkeley.edu
- If a key is generated using the fully-qualified name, and an unqualified name is used in a login attempt, SSH will not authenticate properly and the login will fail.
- Note that in cases where this sort of mistake is made, the client's error message and/or log file may not be very helpful in tracking down what's really wrong...
Testing whether SSH Keys have already been exchanged
If Host Keys have already been exchanged, you'll be able to open an SSH Secure Shell Client window logged in to the server of interest using Public Key authentication (as opposed to Password authentication).
- Open the SSH Secure Shell GUI client
- Request a new connection
- Fill out the server name (remember the name-consistency warnings, above!), your User Name, the Port Number (generally 22 for an SSH connection), and choose "Public Key" from the list of Authentication Methods.
- Click the Connect button.
- If this is the first time you've attempted to use SSH to log on to this server, you'll be asked whether you want to accept and store the server's Host Key. You want to do this.
- If you see a prompt on your CVS server, Host Keys have been correctly exchanged. You're done.
Generate SSH Keys (if necessary)
First, determine whether you have already generated SSH Keys that can be used for key-exchange purposes:
- Open Windows Explorer.
- If you can't already see "hidden" files and folders, navigate to
Tools:Folder Options:View and:
- Assure that Show hidden files and folders is selected
- Assure that Hide file extensions for known file types is not selected
- Assure that Hide protected operating system files (Recommended) is not selected
- Click the Like Current Folder button at the top of the pane.
- Look in the folder C:\Documents and Settings\mylogin\Application Data\SSH (substituting your own login name for "mylogin").
- The public and private keys will be files named something like this: id_dsa_1024_a and id_dsa_1024_a.pub
- If the files already exist, you need not generate them again.
- If the files don't exist, generate them in one of these ways:
- by typing the following
from a Command prompt:
C:\Program Files\SSH Communications Security\SSH Secure Shell\ssh-keygen2; or, - by opening an SSH Secure Shell client (SshClient.exe), navigating to Global Settings : User Authentication : Keys, and clicking the [Generate New] button under Key Pair Management - which launches the Key Generation Wizard.
Note: do not give your key a password (if prompted for one, simply respond by pressing the [Enter] key). If your key has a password, you will be required to supply it each time the key is used for authentication, rendering the advantage of using key-based authentication moot. Instead, be sure that permission to the directory where your keys are generated - and where the private key will be stored - is highly restricted ... e.g., only you have permission to read files stored in it.
- by typing the following
from a Command prompt:
- The files described above should now exist in your C:\Documents and Settings\mylogin\Application Data\SSH directory.
- In the same directory where your key files reside,
create a text file named
identification (note that there's no extension), if
it doesn't exist already. The file should contain a single line,
indicating the name of your private key (match your own private
key name, which may differ from the example):
idKey id_dsa_1024_a
Move user's public key to server
In these steps, the user's public key is transformed from the key format supported by the client machine to that used by the server's implementation of SSH. It is essential to attend carefully to permissions in server directories!
- Log into the server of interest, using the SSH client (password authentication, of course, since public-key authentication isn't implemented yet...)
- If the permissions on your home directory are different from 700
(drwx------), change the home directory permissions:
chmod 700 your_home_dir - From your home directory on the server, create a directory
.ssh if it doesn't already exist:
mkdir .ssh - From your home directory on the server,
set permissions on the new directory:
chmod 700 .ssh - Copy your public key (the one with the .pub extension) from the client Windows filesystem to your home directory on the server.
- From your home directory on the server, run the following command to convert
the Windows-format public key to the format, name, and location
your CVS server needs and concatenate it onto the
authorized_keys file (this command will create
authorized_keys if it doesn't exist yet...; note that
you should use the name of your own public key file if it is
different from the example ):
ssh-keygen -i -f id_dsa_1024_a.pub >> .ssh/authorized_keys - The .ssh/authorized_keys file now contains a converted copy of your public key. Erase the copy of the Windows-format public key you placed into your home directory.
- From your home directory, set permissions on the
authorized_keys file:
chmod 644 .ssh/authorized_keys
Testing and Troubleshooting
Try again to log in using public-key authentication, as described above. If it doesn't work, the most likely culprit is permissions settings on the server. They should be as follows:
- Home Directory: drwx------ (700)
- .ssh Directory: drwx------ (700)
- authorized_keys file: -rw-r--r-- (644)