Password-less Encrypted Connections with OpenSSH

January 2006

Password-less Encrypted Connections with OpenSSH

Believe it or not a lot of users out there do not know how to set up password-less encrypted connections with OpenSSH. While there are many sites (and manual pages) with this information, it is getting put up here as a quick [1] reference. [2]

Public Keys

Setting up a no-password needed secure shell connection involves public keys. A public key is the the id needed on both ends to agree upon a session - at least that is the short short version. The basic steps of setting up SSH keys is:

Generate the keys on the client host.
Copy or deposit the keys on the server.
Test the connection.

Conventions

While the typographic are inline with what the site usually uses, the host conventions need to be clarified.

client: The system that a user is connecting from and that the full ssh directory will reside on.
server: The system that the client is connecting to and will only have the files within the ssh directory that are needed.

Generating Keys

First the type of key needs to be determined, as of this writing there are two types:

More recent versions of OpenSSH default to version two DSA keys. In this example sshv2 and DSA will be used.

jdoe@client: ssh-keygen -t dsa

When the passphrase comes up, since this is for no-pass connections, hit enter for each prompt (including the passphrase). Now in jdoe's home directory, a .ssh directory exists with the following files:

jdoe@client: ls -al /home/jdoe/.ssh
-rw-------   1 jdoe jdoe  668 2005-12-22 04:52 id_dsa
-rw-r--r--   1 jdoe jdoe  598 2005-12-22 04:52 id_dsa.pub

The public key file to be used is, id_dsa.pub.

Sending the pub key to the Server

Ideally, this could be done via some sort of ultra secure method. In most cases sending the key file over is simply a matter of secure copying it. The problem with just secure copying it is that the directory bits may not be in place on the server. To make sure they are, at least one semi-interactive session is required. Assuming that jdoe's home directory is in the same place on the server as the client then the following works with the exception that jdoe will be prompted for a confirmation to connect then a password for each operation. Note that the connect confirmation is only requested once:

jdoe@client: ssh server mkdir /home/jdoe/.ssh
The authenticity of host 'server.server.srv (192.168.0.50)' can't be established.
DSA key fingerprint is xxsomereally:long:list
Are you sure you want to continue connecting (yes/no)? 
yes
jdoe.server.srv's password:
jdoe@client: ssh server chmod 0600 /home/jdoe/.ssh
jdoe.server.srv's password:

Now that the permissions and structure are in place, it is time to send the public keys:

jdoe@client: scp .ssh/id_dsa.pub server:/home/jdoe/.ssh/authorized_keys
jdoe.server.srv's password:

That is it, from now one when jdoe types:

jdoe@client: ssh server

As long as the client and server are on the same version (again - nowadays v2) of the protocol - the connection will no longer require a password. This applies to scp as well.

What about Version Differences?

That is simple enough, newer versions now pass along the information and automatically adjust. In the worst case scenario, run ssh in verbose mode (-v) to see what protocol is on the server and then change the client connection to use it with the -o -NUMBER where NUMBER is the version. If the keys are incompatible, the verbose option will say which keys to use, to use RSA simply run

jdoe@client: ssh-keygen -t rsa

Which will create key files named id_rsa and id_rsa.pub. The pub file is still copied to server:$HOME/.ssh/authorized_keys.

The Quick Guide

Following is a simple summary with user jdoe and their $HOME being the same on the client and server as well as using v2 with DSA:

jdoe@client: ssh-keygen -t dsa
jdoe@client: ssh server mkdir /home/jdoe/.ssh
The authenticity of host 'server.server.srv (192.168.0.50)' can't be established.
DSA key fingerprint is xxsomereally:long:list
Are you sure you want to continue connecting (yes/no)? 
yes
jdoe.server.srv's password:
jdoe@client: ssh server chmod 0600 /home/jdoe/.ssh
jdoe.server.srv's password:
jdoe@client: scp .ssh/id_dsa.pub server:/home/jdoe/.ssh/authorized_keys
jdoe.server.srv's password:
jdoe@client: ssh server

Summary

OpenSSH offers a lot of capabilities not documented here (yet?) - in the least, setting up password less accounts is pretty straightforward and easy enough for just about any *NIX user.