January 2006
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]
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:
While the typographic are inline with what the site usually uses, the host conventions need to be clarified.
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.
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.
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.
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
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.
(based on last 2 months log reports)
