[Beowulf] Password less ssh

[Robert G. Brown]

On Wed, 8 Dec 2004, Sean Dilda wrote:

> Suvendra Nath Dutta wrote:
> > On this note, I know this has been rehashed many times before, but using 
> > OpenSSH 3.8 on SUSE 9.1, I couldn't get host authentication to work. I 
> > followed all the instructions out in the web but everything failed. I 
> > ended up copying the root's dsa key to every user's ssh directory and 
> > using public-key authentication. Has someone successfully implemented 
> > host authentication using SSH (hopefully v2) 
> 
> Yes
> 
> and has written it up in a
> > nice How To?
> 
> No :)

Actually, there IS a mini-HOWTO out there on the web.  I can't remember
the URL, but google for it and you'll find it.

Here is a snippet from my March CWM column of last year as well.
Probably doesn't contain anything "new" compared to what folks have
already told you, but just in case.

%< snip snip snippet ==============(forgive the markup)=================
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:
C<
rgb at lucifer|T:151>ssh lilith
The authenticity of host 'lilith (192.168.1.131)' 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,192.168.1.131' (RSA) to the list of
known hosts.
rgb at lilith's password: 
rgb at lilith|T:101>
>

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:  
C<
rgb at 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/id_rsa.pub.  
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.
C<
rgb at lucifer|T:113>cd .ssh
rgb at lucifer|T:114>ls
id_rsa  id_rsa.pub  known_hosts
rgb at lucifer|T:115>cp id_rsa.pub authorized_keys
rgb at lucifer|T:116>cd ..
rgb at lucifer|T:118>scp -r .ssh lilith:
rgb at lilith's password: 
known_hosts 100% |*****************************| 231 00:00    
id_rsa 100% |*****************************| 883 00:00    
id_rsa.pub 100% |*****************************| 220 00:00    
authorized_keys 100% |*****************************| 220 00:00
rgb at lucifer|T:120>ssh lilith
rgb at lilith|T:101>
>
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 I<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 we'll get PVM itself going.

(Sorry about the "PVM", but this was a column on running PVM.  Obviously
it is the same set of steps for MPI).

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu