General

We were faced with the problem of managing several hundred remote servers via SSH and handling the passwords for all machines was very laborious and not scriptable. This guide describes how to configure a system to use public key authentication with SSH-Agent for automatic remote login.

We assume that you can already get remote access via SSH, using a username/password and want to add public key access to the system.

It is important to understand how public key authentication works: To connect from a local to a remote machine, you have to generate a key pair on the local machine and copy the public key to the remote machine, then add it to the authorized_keys file of the remote machine.

Using public key authentication you can connect to the remote machine without having to furnish it with a password, but you still need to provide your own machine with an even longer passphrase to unlock your own private key. SSH-Agent can be used to keep your private key in RAM, thus relieving you from having to type the passphrase every time you connect to a remote machine. Once ssh-agent is running, you can create scripts to connect to many different machines, without having to enter passwords or passphrases.

Configure the System

[remotemachine]$ ssh -V

You should see a version number greater than 2.x and support for protocol 2.0. If not, then you need to upgrade.

Use ssh-keygen to create a set of private/public keys on the local machine:

[localmachine]$ ssh-keygen -t dsa
Press enter when it asks for a filename
Type the passphrase and write it down - lest you forget it.

The passphrase is used to protect your private key. The public key doesn't need any protection, that is why this is called public key encryption.

In directory ~/.ssh, you will now have two new key files: id_dsa and id_dsa.pub. You will also see files authorized_keys and known_hosts.

Key Distribution

You have to copy the public key of the local machine(s) to your remote machine(s), in order to connect from the local to the remote machines. The remote machine needs to authenticate the local machine, therefore it needs the public key of the local machine.

Do not use FTP to copy the key file, rather use scp. The scp syntax is similar to cp, except for the addition of username@hostname:

[localmachine]$ scp id_dsa.pub user@remotemachine:~/.ssh/localmachine.pub

Add the local machine public key to your remote machine authorized_keys file:

[remotemachine]$ cat localmachine.pub >> authorized_keys

This will create file ~/.ssh/authorized_keys if it doesn't exist already.

Rinse and repeat for each remote machine.

Permissions

SSH is very sensitive to file permissions - for security reasons. Do the following to ensure SSH will be happy:

$ cd
$ chmod 700 .ssh
$ cd .ssh
$ chmod 600 *

These permissions are extremely important and must be correct on all machines, local and remote.

Test Public Key Authentication

You should now be able to connect to the remote machine using the public key system. SSH will try various authentication schemes and if all else fails, fall back to password authentication. See the Trouble Shooting paragraph if you experience trouble

Verify that your connection uses public key authentication:

[localmachine]$ ssh -v -v -v user@remotemachine

Type your local passphrase when asked and you should get a remote shell.

Trouble Shooting

If you cannot get public key authentication to work between two machines, check the file permissions on BOTH machines. Nine out of ten times, this is the problem, causing SSH to ignore the files with bad permissions, and fall back to password authentication.

You can see what is going on, by using the verbose options of SSH:

[localmachine]$ ssh -v -v -v user@remotemachine

First try to access the machine from its own terminal, before trying to access it remotely. You can do this by adding its own public key to its own authorized_keys file. Then you can ssh to localhost:

[localmachine]$ cat id_dsa.pub >> authorized_keys
[localmachine]$ ssh -v -v -v localhost

Once logged in to the remote machine using password authentication, you can do the same there and log in to itself. This will show whether the problem is locally or remotely.

Configure SSH-Agent

If SSH-Agent keeps our decrypted private key in RAM, we then need only enter the passphrase once after startup. If we switch off, or log out, the passphrase is erased, which is safer than keeping a plain text private key on disk.

In order to automate ssh-agent, we need to add it to our ~/.bash-profile file and cause it to export some environment variables. Edit your ~/.bash_profile and add the following to the bottom:

eval `ssh-agent`

Note that those are accents grave - backticks.

We added ssh-agent to the profile so it will run next time we log in, but for now, we still have to run it manually. We feed our passphrase to ssh-agent, using the ssh-add program:

[localmachine]$ eval `ssh-agent`
[localmachine]$ ssh-add

Type your passphrase when requested.

Now, when we try to connect to the remote machine, ssh will be silent and won't bother us with any questions!

[localmachine]$ ssh user@remotemachine

You will be rewarded with a remote shell. If you don't believe it, simply kill ssh-agent and try to connect again.

[localmachine]$ su
rootpassword
[localmachine]# killall ssh-agent
[localmachine]# exit
[localmachine]$ ssh user@remotemachine

This time, ssh will ask you for your private key passphrase.

Note that this system will also work with RSA keys. If you choose a very long RSA key (>2048 bits), then it may be more secure than DSA keys, but you probably have a much weaker point elsewhere in your security system than these keys - sanity should prevail.

Have fun!

Herman