To use SSH for logging in without a password

SSH keys are created between two machines for the following purposes:

to log in without being asked for a password
to execute a remote command without being asked for a password

Examples of the second reason include accessing our CVS repository, automatically backing up tapes, and automatically copying analysis files to the web. In the first case, the administrator of the CVS repository doesn't want the password for this repository known by many people, and also doesn't want this password being passed, unencrypted, through the Internet. In the second and third cases, the user providing these services doesn't want the password placed in the system files unencrypted. SSH keys solve these problems.

To create an ssh key between two machines, perform the following steps:

Step 1. Generate the keys

On the machine from which you will be connecting, type:

      $  ssh-keygen -t dsa -f {to_machine}

where {to_machine} is replaced with, say, the machine to which you will be connecting. DSA type keys are preferred over RSA, because they are longer, and much more difficult to break.

This command generates these two files:

      {to_machine}
      {to_machine}.pub

These two files form two halves of the SSH key system. The .pub file is the "public" key, the other half is the "private" key.

When automatically backing up tapes or files, passphrases are generally not useful, because they will have to appear unencrypted in system files.

Step 2. Move the public key to the receiving machine.

Copy the .pub file to the machine to which you will be connecting:

      $ scp {to_machine}.pub {user}@{to_machine}:
      {user}@{to_machine}'s password: 
      {to_machine}.pub          100% |*****************************|   606      00:00    
      $ rm {to_machine}.pub

where {user} is the name of the user on {to_machine}.

Step 3. Authorize the public key.

Do this by logging into the machine and then appending the public key to the authorized_keys2 file:

      $ ssh {user}@{to_machine}
      {user}@{to_machine}'s password:
      Last login: Wed May  1 12:33:19 2002 from x.com
      Red Hat Linux Tue Feb  5 05:10:22 CST 2002
      $ cat {to_machine}.pub >> ~/.ssh/authorized_keys2
      $ rm {to_machine}.pub
      $ exit
      logout
      Connection to {to_machine} closed.

Depending on your version of SSH, you may need to try both the authorized_keys and authorized_keys2 files. In general, authorized_keys2 works with our versions of SSH.

Step 4. Move your identity to a safe place.

Move the private key to .ssh, and rename it to have "identity" as part of its name- this is just a convention.

      $ mv {to_machine} ~/.ssh/identity_{to_machine}

Step 5. Test the keys.

Do this by generating an xterm with an associated key agent:

      $ ssh-agent xterm &

and then adding the identity and trying to log in:

      $ ssh-add ~/.ssh/identity_{to_machine}
      Identity added: .ssh/identity_{to_machine} (.ssh/identity_{to_machine})
      $ ssh {user}@{to_machine}
      Last login: Wed May  1 12:33:19 2002 from x.com
      Red Hat Linux Tue Feb  5 05:10:22 CST 2002
      $

When in doesn't work.

Sometimes this doesn't work. Here are some hints.

Make sure that the file {to_machine}:/etc/sshd searches for Protocol 2 first. Here's a good line to have in that file:
                              Protocol 2,1
Make sure your authorized_hosts file is not corrupt It should only have one key per {user}@{to_machine}.
Try using ssh -v in Step 5 to debug the connection.

Good Luck! If you discover any errors or want to suggest any additions or amplifications, please send me a letter.