OpenSSH Automatic Login

Overview

OpenSSH provides a mechanism to use the Digital Signature Algorithm to provide an alternative to manually typing in a password when logging in to a remote machine. This is quite convenient, and I believe more secure than typing in the password, as, among other things, the password characters are sent one at a time to the remote machine, so anybody watching the traffic can infer some details of the password (such as the number of characters!). This automatic login also applies to scp and thus makes that program more convenient.

This method applies to OpenSSH using protocol version 2. I have also used this with the original ssh, but don't have notes about the steps involved. I have had OpenSSH and ssh operate with one another to perform automatic authentication, but have no details of how I did that!

This process involves two machines:

a client machine client.example.domain, which is the one from where the connection and login is started.
a server machine server.example.domain, running the ssh daemon, and to where the login attempt is directed.

This is a one way operation, so you need to repeat these steps from the server machine if you want to have automatic login from the server to the client. Note that this is not necessarily a desirable idea, for instance if the server is a firewall machine, you probably do not want automatic authentication on internal machines, as this simply helps somebody who has broken into the firewall machine.

Creating Keys

On the client.example.domain machine, user1 runs the command

	ssh-keygen -t dsa

to generate the public and private keys, using the DSA algorithm. I used all the default values, and no pass phrase. This is less secure than using a pass phrase, but is more convenient. Your call as to the risk/benefit to you. [If you use a pass phrase, you will be prompted for it each time you use ssh or scp which does rather negate the effect of automatic login. However, it does mean that compromise of your password on the client, or somebody with the root password (administrator access on Windows), does not gain access to other machines using your ID.]

The above creates a pair of files in the ~user1/.ssh directory. These are the public (id_dsa.pub) and private (id_dsa) keys which ssh uses for authentication. The public key needs to be replicated to all servers where you wish to login. The private key is used on the client machine only and should not be copied around. It must be kept private, and to enforce this, ssh will refuse to use it unless it is readable (or readable and writable) only by the owner (i.e. mode 400 or 600). The owner of the file must be user1.

Distributing The PUBLIC Key

Copy the file id_dsa.pub to the server.example.domain machine (e.g. by using scp) and add it to the file ~user1/.ssh/authorized_keys2 file. If this file exists, add the new data to the end; otherwise create the file mode 644. The safest way to do this is to use the commands

      cat id_dsa.pub >> ~user1/.ssh/authorized_keys2
      chmod 644 ~user1/.ssh/authorized_keys2

Note that the ~user1/.ssh/authorized_keys2 file consists of very long lines, one line per client machine configured to automatically login to this machine. Using a text editor with line and/or word wrap will split these long lines, and make the file contents useless!

And that's it.

Logging In As A Different User

If user1 wants/needs to login to the remote machine as user2 the command to use is

      ssh user2@server.example.domain

Adding user1's public key to the ~user2/.ssh/authorized_keys2 file on server.example.domain allows user1 to login on the remote machine as user2 without being prompted for a password.