SSH public-key authentication

1. Introduction

Using cvs over ssh for repository access in RPI CS environment normally involves typing a password for every repository access, which quickly gets frustrating. It also makes it impossible to do automated cvs commands. In this document, we provide a brief overview of the public-key authentication mechanism built into the ssh authentication protocols, and show how this can be used to avoid constantly entering a password.

There are two major varieties of ssh publicly available: the "original" ssh, distributed by SSH Communications Security (http://www.ssh.com), and OpenSSH, developed as part of the OpenBSD project (http://www.openssh.org). The CS department uses OpenSSH clients and servers, so we will restrict our discussion to it. The key ideas are the same for both the commercial ssh and OpenSSH, but the configuration files and such are slightly different. When configured correctly, commercial ssh and OpenSSH clients and servers will inter-operate.

[OpenSSH is available for Windows. I forget the web-link to the binary, though. You may have some success in obtaining it via the OpenSSH website.]

The following only provides the basics needed to get OpenSSH public-key authentication working. Please refer to the ssh man pages for more details.

2. Public-key authentication

The basic idea is that there are two related numbers, called keys, such that a message encrypted by one can be decrypted by the other, and vice versa. One of these keys is called the public key, and the other the private key. As the names indicate, the public key is known to everyone while the private key is known only to you. The private key is used to identify you, and if someone else gets hold of your private key, they can easily masquerade as you.

The authentication works essentially like this. The server knows your public key, you know your private key. The server generates a random message and encrypts it using your public key. This message can only be decoded using the corresponding private key, so only you can decode it. The server sends you the message, and you decode it and send it back to the server. The server checks what you sent back against what it originally generated. If the two match, then you were successful in decoding the message, and therefore, you must know the private key, and hence, you are who you say you are.

Again, note that the authentication mechanism merely checks that the client (user) knows the private key. It is vital that you protect this key; giving it out is equivalent to giving out your password.

To use public-key authentication, then, we need to: (1) generate the public and private keys; (2) tell the server what the public key is; and (3) tell the client what the private key is.

3. Generating the public-private key pair

There are different two different types of keys that can be used: RSA keys (used in version 1 of the ssh protocol) and DSA keys (used in version 2 of the protocol). Depending on the server and client configuration, a session could use either version 1 or version 2 of the protocol. We will, therefore, generate both types of keys and set up the server and client to use public-key authentication for both protocols.

ssh (both versions) normally stores all its information (configuration files, keys, etc) in ~/.ssh under Unix. Under Windows, this directory is configurable. In the following, we will use ~/.ssh to refer to the directory where OpenSSH stores its information.

Generate RSA keys under OpenSSH by running ssh-keygen. A sample run:

*pre perera $ ssh-keygen
Generating RSA keys:  Key generation complete.
Enter file in which to save the key (/cs/perera/.ssh/identity): /cs/perera/tmp/cvskey_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /cs/perera/tmp/cvskey_rsa.
Your public key has been saved in /cs/perera/tmp/cvskey_rsa.pub.
The key fingerprint is:
c1:7b:83:1f:77:77:d7:14:06:6e:33:54:73:65:cb:1b perera@pre.vision.cs.rpi.edu
*pre perera $ 

We now have two files: ~/tmp/cvskey_rsa (the private key) and ~/tmp/cvskey_rsa.pub (the public key). For additional security, it is possible to encrypt the keys with a passphrase. You should not do this, as the point is to be able to use cvs without a passphrase.

Similarly, generate a DSA keypair by running ssh-keygen -d:

*pre perera $ 
*pre perera $ ssh-keygen -d
Generating DSA parameter and key.
Enter file in which to save the key (/cs/perera/.ssh/id_dsa): /cs/perera/tmp/cvskey_dsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /cs/perera/tmp/cvskey_dsa.
Your public key has been saved in /cs/perera/tmp/cvskey_dsa.pub.
The key fingerprint is:
46:5b:cf:28:79:89:1f:67:6a:4e:18:c5:6e:68:55:19 perera@pre.vision.cs.rpi.edu
*pre perera $ 

4. Informing the server of the public keys

The server uses the file ~/.ssh/authorized_keys to determine which key pairs may be used for authentication (~/.ssh/authorized_keys2 for protocol 2). We add our newly generated keys to list of authorized keys: (this should be run on the server--one of the CS Unix machines)

*pre perera $ echo '# cvs key' | cat - ~/tmp/cvskey_rsa.pub >> ~/.ssh/authorized_keys
*pre perera $ echo '# cvs key' | cat - ~/tmp/cvskey_dsa.pub >> ~/.ssh/authorized_keys2
*pre perera $

Since the CS Unix systems use a single shared filesystem, the above addition will allow any Unix system to be accessed using the new private keys. This includes the cvs servers.

5. Informing the client of the private keys

First, you need to get the private keys onto the client. You can use any mechanism you want. We recommend a secure mechanism, such as scp. Once the keys are on the client, you need to put them in ~/.ssh and tell the client to use them.

   [copy the private keys over]
   mv cvskey_rsa cvskey_dsa ~/.ssh

Edit the file ~/.ssh/config and add the following lines:

Host vxlcvs.cs.rpi.edu
   IdentityFile  /cs/perera/.ssh/cvskey_rsa
   IdentityFile2 /cs/perera/.ssh/cvskey_dsa
Host rpilcvs.cs.rpi.edu
   IdentityFile  /cs/perera/.ssh/cvskey_rsa
   IdentityFile2 /cs/perera/.ssh/cvskey_dsa

(The Host declaration accepts wildcards. See the ssh man page for more details.)

6. Additional clients

You should now be able to ssh into vxlcvs.cs.rpi.edu and rpilcvs.cs.rpi.edu without using a password. This means that you can run the cvs commands without being prompted for a password. To test simply try ssh vxlcvs.cs.rpi.edu.

To allow additional clients (e.g. your laptop, your home machine), you could copy the private keys over to those machines and configure appropriately. In order to minimise security breaches, however, we recommend you generate a separate keypair for each machine. That is, the laptop would have its own keypair, the home machine another keypair, and so on. That way, if the laptop were misplaced, or the key copied off the laptop, you could revoke just that key (by removing it from the authorized_keys), and not have to reconfigure all the other clients.

Table of Contents

1. Introduction
2. Public-key authentication
3. Generating the public-private key pair
4. Informing the server of the public keys
5. Informing the client of the private keys
6. Additional clients

Short Table of Contents

1. Introduction
2. Public-key authentication
3. Generating the public-private key pair
4. Informing the server of the public keys
5. Informing the client of the private keys
6. Additional clients

About this document

where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:

• 1. Section One
  • 1.1 Subsection One-One
    • ...
  • 1.2 Subsection One-Two
    • 1.2.1 Subsubsection One-Two-One
    • 1.2.2 Subsubsection One-Two-Two
    • 1.2.3 Subsubsection One-Two-Three     <== Current Position
    • 1.2.4 Subsubsection One-Two-Four
  • 1.3 Subsection One-Three
    • ...
  • 1.4 Subsection One-Four