Article Index


If you are running a Red Hat based cluster that was professionally setup as a LAN with a NFS exported home directory, chances are very good that ssh is already installed and ready to run. You can easily check by issuing the following:

$rpm -qa|grep openshh

If these packages (possibly with different version numbers and patch levels) are NOT already installed, you will need to install them from RPMs provided for your system (or get your systems administrator to install them for you). There may be a few more openssh packages installed as well depending on the needs of your site. The server package installs the ssh daemon (which listens on a port for incoming connections and services them). The ssh program itself is used to connect to remote hosts and is in the clients package along with other userspace ssh-based programs and utilities. Both the client and the server packages require the basic openssh package to function.

To install the required RPMs if they are not already installed, you will need to become root and enter something like:

#rpm -Uvh openssh-3.5.p1-11.i386.rpm

and repeat for the other missing rpm's in dependency order on each node of the cluster.

Once the daemon is installed, you may still need to configure it to start at every reboot and/or start it up for the current session. To find out, use chkconfig:

$chkconfig --list sshd
sshd   0:off  1:off  2:on  3:on  4:on  5:on  6:off

As you can see, this daemon is configured to start up at run levels 2-5. Read man chkconfig to see how to set up or alter this (sensible) base configuration. To get it running right after installing it you can either reboot or start it by hand:

#/etc/init.d/sshd start
Starting sshd:             [  OK  ]

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 log into the remote host at all, with a password:

$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 step 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:

$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 ~/.sshdirectory. If your home directory is NFS exported to all the nodes,then you are done; otherwise you'll also need to copy the entire .sshdirectory to all the hosts that don't already have it mounted. The following illustrates the steps and a test.

$cp .ssh/ .ssh/authorized_keys
$scp -r .ssh lilith
rgb@lilith's password: 
  progress bars
$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 manpag(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. Go do that, and then next time we'll get PVM going.

Sidebar One: Projects Mentioned in Column
PVM Home Page

PVM Users Guide PVM: A User's Guide and Tutorial for Networked Parallel Computing, Geist, Beguelin, Dongarra, Jiang, Manchek and Sunderam (MIT press)

PVM Users Guide Online

SSH without Passwords by Arun Vasan


This article was originally published in ClusterWorld Magazine. It has been updated and formated for the web. If you want to read more about HPC clusters and Linux, you may wish to visit Linux Magazine.

Robert Brown, Ph.D, is has written extensively about Linux clusters. You can find his work and much more on his home page

You have no rights to post comments


Login And Newsletter

Create an account to access exclusive content, comment on articles, and receive our newsletters.


Creative Commons License
©2005-2019 Copyright Seagrove LLC, Some rights reserved. Except where otherwise noted, this site is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. The Cluster Monkey Logo and Monkey Character are Trademarks of Seagrove LLC.