RSA Authentication for SSH

SSH, and its related utilities like scp and sftp, make up the core tools for safely communicating across the network. By default, SSH sessions are authenticated by typing in passwords, but this can be awkward to do in scripts and inconvenient or impossible in some situations. Rather than using passwords, one can set up RSA keys which are exchanged by client and server for authentication.

SSH public/private key pairs

In order to avoid typing passwords, a public/private key pair may be used. The public key is not secret and can be freely distributed. The private key is secret and it must be safeguarded as anyone who possesses the private key possesses the identity it represents.

Here's how the keys work. The public key is used by a client to encrypt a message for the owner of the private key. Only the private key can decrypt messages encrypted by the public key. When a client first connects to a server, they each symmetrically use this technique to set up an encrypted channel between them by exchanging public keys. From that point forward all communication goes over the encrypted link which is why ordinary ssh can then be used to supply the user's password.

However, it's also possible to employ key pairs for authentication. Before attempting to authenticate the user with a server, the client authenticates the server by asking for that server's public key and searching for a match by the server's name in the known_hosts file on the client. If it's not found, the client asks its user whether to continue by accepting the server's public key. (It's also possible for the server to challenge the client to identify itself using a public key authorized by the server, but we don't require this)

To use the server's ssh services, the client uses the public key of the server to send the server the public key of the user. At its end, the server searches a list of authorized public keys and, if matched, uses the key to create a challenge for the client. A client possessing the corresponding private key will be able to decode the challenge and return a response. When the server receives the correct response it knows that the client possesses the users private key and so grants the user access.

Notes:

"ssh -v ..." causes the login negotiation to be displayed and is useful in debugging.
ssh clients silently refuse to use private keys if .ssh or its parent directory is group or world writable
The host name used when searching known hosts files is the exact name used for the connection, e.g. "gpo" is distinct from "gpo.stanford.edu".

For all command options and additional information, see the OpenSSH manual pages.

Setting up personal SSH V2 RSA keys

The following instructions are for setting up an identity in the home directory of user descartes on the unix cluster under ~descartes/.ssh. Because the home directory is generally mounted by all machines, a single set of keys is sufficient. For the keys to work, the client machine must find the private key saved where the ssh client expects it and it must store the public key of each server in the ~descartes/.ssh/known_hosts. For the server to accept the key for authentication, the public key must be found in ~descartes/.ssh/authorized_keys file.

Create .ssh directory

mkdir -m 700 .ssh

cd .ssh
You may also put a config file in this directory to set defaults. One handy default is to have your RSA key forwarded on if you ssh again. To do this, add the following lines:

Host *

ForwardAgent yes

Create SSH V2 RSA identity with ssh-keygen
There are two versions of the SSH protocol and each version can have an RSA identity. Although the version 1 protocol is valid, it is no longer the default when using ssh. Unfortunately version 1 is the default when using the key generation utility so you must be careful to specify that you want "-t rsa" when creating keys.
ssh-keygen -t rsa -f id_rsa
generates a keypair under the default name for version 2. You will be given the chance to specify a passphrase which ssh will use to encrypt the private key. This passphrase provides strong additional security, especially on the cluster home directories where preventing access to the private key cannot be guaranteed. The use of a passphrase is now strongly recommended.
One can now easily use passphrase protection for all identities, including ones used by helper programs such as ssh tunnels for mail clients. The ssh-agent and ssh-add commands on Unix and Cygwin and Putty's Pageant service permit you to enter the passphrase once to unlock the private key for use with all clients for the rest of your session. OS-X 10.5 and later understand passphrase-protected keys and will store them in your keychain.
Without a passphrase it's critical that the private key file permissions allow only you to access it.
Create authorized_keys file (writable only by owner)
touch authorized_keys

chmod 600 authorized_keys

Add the public key to authorized_keys file
cat id_rsa.pub >>authorized_keys

Perform initial login to accept and add host public key to known_hosts file
ssh gpo.stanford.edu date

Note: If you copy the .ssh directory to a Cygwin home directory on Windows, then you can ssh without passwords from that machine as well.

Setting up CVS to use SSH V2 RSA keys

To use CVS securely in a remote setting you should use SSH and you can use RSA identities, like the one created above, to avoid password prompts.

Independent CVS users

When the CVS repository is on a machine where everyone has an id, then if each person sets up an identity as above, all they need do is tell CVS to use SSH by setting up an environment variable:

CVS_RSH=ssh

Shared Common CVS user

Sometimes it's more convenient or necessary to have all the CVS commands executed as single local user on the server.
This can be done as follows:

On the CVS server (e.g., repository.stanford.edu) in the home directory of the local id you will use for CVS (e.g. ~hotproj) append the public key part of one or more ssh identities (the content of ~descartes/.ssh/id_rsa.pub above) to the file ~hotproj/.ssh/authorized_keys. The authorized_keys file can have keys in it from as many remote users as you wish.
On the client set the environment variable CVS_RSH=ssh
Each client CVS command uses hotproj@repository.stanford.edu when connecting to the repository

The CVS requests are transformed and issued with "ssh hotproj@repository.stanford.edu cvs...."

The client ssh picks up the key in ~descartes/.ssh/id_rsa.pub and sends it to the sshd on repository.stanford.edu.
the sshd server on repository looks in ~hotproj/.ssh/authorized_keys and if the key sent is found there, the CVS command is executed as userid hotproj.

You only need a single private/public keypair. As long as the client has the private key and the server has the public key in its authorized_keys, file, you're good-to-go. You could reuse your existing keys if you want. You could even use the same keypair for all CVS users although that means if the key is ever compromised, all users will have to get a new one.