Passwordless SSH Logins

From Cluster Documentation Project
Jump to: navigation, search

DISCLAIMER: Implemeting any of these techniques will allow you to login to the target system without being prompted for a password. In all but one set of circumstances this is a very, very, very BAD thing.


The info below comes from an RGB (Robert G Brown) at Duke Uni, USA, posting on the Beowulf list.

Now, let's arrange it so that we can login to a remote host (also running sshd) without a password. Let's start by seeing if we can login to the remote host at all, I<with> a password:

rgb@lucifer|T:151>ssh lilith

The authenticity of host 'lilith (' can't be established.

RSA key fingerprint is 8d:55:10:15:8b:6c:64:65:17:00:a7:84:a3:35:9f:f6.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'lilith,' (RSA) to the list of known hosts.

rgb@lilith's password:



So far, so good. Note that the FIRST time we remotely login, ssh will ask you to verify that the host you are connecting to is really that host. When you answer yes it will save its key fingerprint and use it thereafter to automatically verify that the host is who you think it is. This is one small part of the ssh security benefit. However, we had to enter a password to login. This is no big deal for a single host, but is a BIG deal if you have to do it 1024 times on a big cluster just to get pvm started up!

To avoid this, we use the ssh-keygen command to generate a public/private ssh key pair of our very own:

rgb@lucifer|T:104>ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/rgb/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/rgb/.ssh/id_rsa.

Your public key has been saved in /home/rgb/.ssh/

The key fingerprint is: c3:aa:6b:ba:35:57:95:aa:7b:45:48:94:c3:83:81:11


This generates a default 1024 bit RSA key; alternatively we could have made a DSA key or increased or decreased the number of bits in the key (decreasing being a Bad Idea). Note that we used a blank passphrase; this will keep ssh from prompting us for a passphrase when we connect.

The last step is to create an authorized keys file in your ~/.ssh directory. If your home directory is NFS exported to all the nodes, then you are done; otherwise you'll also need to copy the I<entire .ssh directory> to all the hosts that don't already have it mounted. The following illustrates the steps and a test.

rgb@lucifer|T:113>cd .ssh


id_rsa known_hosts

rgb@lucifer|T:115>cp authorized_keys

rgb@lucifer|T:116>cd ..

rgb@lucifer|T:118>scp -r .ssh lilith:

rgb@lilith's password:

known_hosts 100% |*****************************| 231 00:00

id_rsa 100% |*****************************| 883 00:00 100% |*****************************| 220 00:00

authorized_keys 100% |*****************************| 220 00:00

rgb@lucifer|T:120>ssh lilith



Note that with the last ssh we logged into lilith with no password!

ssh is really pretty easy to set up this way; if you read the man page(s) you can learn how to generate and add additional authorized keys and do fancier things with it, but many users will need no more than what we've done so far. A warning - it is a good idea to log into each host in your cluster one time after setting it up before proceeding further, to build up the known_hosts file so that you aren't prompted for each host the first time PVM starts up a virtual machine.


A closing note or two:

When compiling / running MPI 1.2x remember either the "setenv P4_RSHCOMMAND ssh" or run configure with "-rsh=ssh" This means you don't have to worry about it from then on.

Most Linux distro's are setup with some sensible default firewall settings. Remember to modify them so SSH is allowed in both directions!


For what is an insecure process, using the "R" untilites is truly evil. There's a fair degree of implementation difference between distro's too. The RedHat flavours and derivatives all seem to be vaguely similar. Regardless, you're aiming for the non-Kerberos version of the "R" utilites.

Rather than repeast the whole process, this procedure has worked for the author: From here:

A couple of comments... In some respects the R utilites are quicker than their chatty SSH cousins. However, this becomes irrelevant after MPI starts up (that by design handles its own comms after the link is established). Also a lot of utilites leave their SSH connection open rather than rsh which they rerun on every request (eg. MOODSS).

Seriously think about *why* you want RSH/RLOGIN. As you can see above, SSH isn't hard and (I'd argue) a bit easier!