SSH and SSH Keys

Overview

SSH, besides using a password, can use keys to authenticate itself to a remote server. A key is nothing more than a set of binary bits whose size is quite small. Two keys are needed for SSH authentication, a private key and a public key. These two keys are created at the same time and are related. The private key is kept by you, and the public key is placed wherever you want a passwordless login. When you log into a remote server, a dialog is established where the public key is encrypted and then decrypted by the private key. If the keys match, then SSH logs the user into the remote server. If the keys do not match, the remote server defaults to asking for a password.

SSH keys are very useful not only to avoid the hassle of typing in a password every time, but for any script or cron job that needs access to a remote server. Since SSH can also execute remote commands the use of keys allows incredible flexibility.

Important: There are two types of SSH keys: RSA and DSA. Either kind can be generated but RSA is preferred because they will work on virtually any SSH server, whereas DSA keys will only work with SSHv2 and OpenSSH servers.

Generating SSH Keys

Before we can generate SSH keys, we need to know what version of SSH is on your machine. 9 times out of 10 (and everywhere here at UVic HEP) that version is OpenSSH. Issue the command ssh -V to find out what you're running.

Now we're ready to generate our private and public keypairs. Issue the following command:

ssh-keygen -b 4096 -t rsa

You don't want to include a passphrase, as that would negate the point of trying to set up a passwordless login. Just hit <return> to create a key with no passphrase. The private key is then put into a file named ~/.ssh/id_rsa while the public key is put into ~/.ssh/id_rsa.pub. You can optionally give the key a different name by adding the -f <filename> option to the ssh-keygen command.

Note: To create a dsa key, simply specifiy -t dsa instead of -t rsa.

Note: The -b option specifies how many bits the key should be. The default is 2048, but at this date 2048-bit keys are considered a bit on the insecure side. 4096-bit keys should be secure for at least the next couple of years.

Setting Up the Keys

Now you will need to copy your public key to the server where you want to be able to use a passwordless login. In this case, I will copy the public key to the remote server mercury.uvic.ca, where I have an account. The command scp is perfect for this (newer openSSH versions include a utility ssh-copy-id that can be used for this step): scp ~/.ssh/id_rsa.pub mercury.uvic.ca:~/.ssh/

Warning! If you have never used SSH on the remote server, then the .ssh directory might not exist, to fix this log into the remote host and issue an ssh <host> where <host> is some server runnig ssh. This will create your .ssh folder with proper permissions. Repeat the scp copy above to move the public key to the remote server.

Now you will need to log into the remote server in order to properly configure the key. Log in and go to the .ssh directory and then do an ls:

ssh mercury.uvic.ca
cd .ssh
ls

If you don't have a file authorized_keys then rename the public key to this file:

mv id_rsa.pub authorized_keys

If that file already exists, then add the new public key to the file as follows:

cat id_rsa.pub >> authorized_keys

Note: When SSH V2 first came out it wanted SSH V2 keys to be stored in authorized_keys2. This is no longer required, so store all public keys in authorized_keys only.

Now log out of the remote server and try log in again, this time no password should be required. If the passwordless login fails check the permissions of your local and remote .ssh directory as well as the permissions of the SSH private key. Also, if you named your SSH key something other than the default (id_dsa or id_rsa) then you will have to ssh to the remote host as follows:

ssh -i ~/.ssh/<private_key> <remoteserver>

Now distribute the public key to all remote computers that you would like a passwordless login to.

 
 
Back to Navigation