|
|
Passwordless SSH (and RSH) Logins
DISCLAIMER: Implementing 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.
OpenSSH Public Key Authentication
The info below comes from Robert G Brown (aka RGB) at Duke University email 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 (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@lilith's password: rgb@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:
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/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.
A more secure option is to use a non-blank passphrase. In this case, you will have to use a couple more ssh tools (once per session).
guest@localhost$ ssh-agent $SHELL guest@localhost$ ssh-add Enter passphrase for /home/guest/.ssh/id_rsa: Identity added: /home/guest/.ssh/id_rsa (/home/guest/.ssh/id_rsa)
If entering the passphrase once per session is annoying, then you should try keychain, which will reuse ssh-agents across all of your sessions. The associated IBM developerWorks articles are very nice introductions to openssh public key authentication.
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 rgb@lucifer|T:114>ls id_rsa id_rsa.pub known_hosts rgb@lucifer|T:115>cp id_rsa.pub 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 id_rsa.pub 100% |*****************************| 220 00:00 authorized_keys 100% |*****************************| 220 00:00 rgb@lucifer|T:120>ssh lilith rgb@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 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.
[end]
A closing note or two:
For RedHat and derivatives, the permissions are quite fussy:
chmod 644 ~/.ssh/auth*
chmod 755 ~/.ssh
When compiling / running MPI 1.2x remember either the "setenv P4_RSHCOMMAND ssh" or run configure with "-rsh=ssh" (it'll whinge that you should use the command line option - ignore it)
Most Linux distro's are setup with some sensible default firewall settings. Remember to modify them so SSH is allowed in both directions!
OpenSSH hostbased authentication
A cluster adminstrator may want to save his users the trouble of setting up public keys themselves by enabling hostbased authentication. Keep in mind that if someone compromises your trusted host(s), then they will have comprimised your entire cluster.
RLOGIN and RSH
There's a fair degree of implementation difference between distro's. The RedHat flavours and derivatives all seem to be vaguely similar. You always want the non-Kerberos version of the "R" utilites. Rather than producing the whole thing, here's a link to an articles that worked for the author:
Here's the upstream URL too: http://howto.x-tend.be/openMosixWiki/index.php/ -> Stick "RSH" in the search box.
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!
