Password-less SSH Connections & What Can Go Wrong

So, you would like to jump from server to sever over SSH without being prompted for a password each time. Or perhaps you have a script or application that needs to access information on a remote server via a SSH tunnel. Using SSH shared key authentication makes this possible.

Shared key authentication is easy enough to set up, but there are a couple of pitfalls that can have you pulling out your hair if things don't work after you have followed the instructions exactly.

Let's consider the following two server scenario:

Server 1:  AIR
Server 2:  WATER

Suppose there is a user "bill" on both servers. Bill usually works on AIR and frequently needs to perform tasks on WATER, he would like to use shared key authentication.

AIR has a /etc/hosts file entry for WATER and vice versa. 


First Bill logs onto AIR and issues the following command
ssh-keygen -t rsa

Now might be a good time to mention that there are other options you could use the ssh-keygen command with to create different types of keys with a variety of key lengths. For this example we'll just use the default rsa key type.

When you hit enter after this command you will see:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/bill/.ssh/id_rsa):

Accept this default path and hit enter.

You'll be prompted for a pass phrase, once to create it then again to verify, leave it blank and hit enter each time.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/bill/.ssh/id_rsa.
Your public key has been saved in /home/bill/.ssh/id_rsa.pub.
The key fingerprint is:
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX bill@air

For this next step to work there should be at least a ~/.ssh/ directory on the WATER server under bill's account. An easy way to achieve this is to perform the same key generation sequence on WATER that we did on AIR. Once this is done we'll have .ssh directories on each of the servers. The next step is to add the public key of the server we are coming from to the authorized_keys file of the server we are going to.

When we are on AIR we can issue the following command:
cat ~/.ssh/id_rsa.pub | ssh bill@WATER "cat - >> ~/.ssh/authorized_keys"

You might be prompted to store the remote server's RSA info to the local system if this is the first time you are connecting. Bill will also be prompted for his WATER password this time.

This command will load the local (AIR) public key into the remote (WATER) server's authorized_keys file. From this point forward bill's SSH authentication from AIR to WATER can now be handled through a key exchange.

Now if bill is on AIR and issues a simple SSH command:
ssh WATER

He will be granted a direct password-less connection. This is great if bill wants to establish a script using scp to copy items from AIR to WATER, the script won't prompt for a password.


Congratulations!  Oh.. wait.. it didn't work ??


Now.. what to check if things don't work.
There are a few not so obvious things that can leave you pulling your hair out.

Improper permissions are usually the most obscure type of issue.

• Permissions on your home directory. The user you are remoting as should be able to read the remote user's home directory. Think about our example above, Bill may not have the same user number on both servers. If the numbers are different then Bill looks like a different person on each server OS. You can achieve this via a group or public permission depending on your security needs.

• Permissions on the authorized_keys file should be set to:
  -rw-r--r--   in other words:  644
  Also, you (bill in this case) should own these files, respectively on each server.

• If you have copied keys manually by copy and pasting or FTP, you may have broken the key, check for proper file encoding and stray characters or carriage returns.

• If you are setting this up on a root account you should check the /etc/ssh/sshd_config file to ensure the PermitRootLogin without-password option is enabled.

• If you have your home directory NFS 4 mounted on the remote server you'll need to use something like rcp.idmapd to ensure the user and group ownership information is associated correctly on the remote system. The default is usually to place the nobody user and group as the owner of the files. A quick fix is to add the specify vers=3 in the in the fstab file mount option.

Hopefully these tips get you up and running, if you find another issue please tell us about it.