The Beowulf list discusses rsh vs. ssh (again), using Raw Ethernet (a Neandertal approach?), and Cluster Computing Courses
The Beowulf mailing list provides detailed discussions about issues concerning Linux HPC clusters. In this article I review some postings to the Beowulf list on rsh vs ssh, using raw Ethernet, and cluster computing courses.
rsh Without Passwords
To run parallel jobs on a cluster you need some way to access compute nodes without a password. On July 7, 2004, Sandeep Krishnan asked how one configures rsh to not use passwords. He could login into the compute nodes from the head node without a password but couldn't login from one compute node to another without first supplying a password. Andrew Cater was the first one to respond to this posting by saying that you should use ssh instead of rsh. He mentioned that there was a ssh " hack" floating around that allows ssh to behave just like rsh.
Sean Dilda also responded that he found ssh host based authentication to be very nice. Daniel Pfenniger took issue with the comments that ssh was better than rsh and wanted to know why it was better (details rather than generalities). This discussion was a very nice introduction for ClusterMonkey's Robert Brown to explain why ssh is better than rsh. Robert has written a great deal about why he believes ssh is better and has also performed some tests comparing the two packages. His first comment was to explain what is wrong with rsh: 1) no security at all, 2) no environment passing, 3) no tunneling/port forwarding, 4) no intrinsic X11 support, 5) archaic and easily spoofed/snooped authentication mechanism, 6) terrible control for " no password" login, and 7) more or less frozen, unsupported code. He thought the only good thing about rsh was that it was relatively fast.
On the other hand Robert thought that ssh has a number of good points: 1) strong security, 2) environment passing, 3) port tunneling/forwarding, 4) intrinsic X11 support, 5) strong host authentication, 6) strong personal authentication, 7) bidirectional encryption, not easily snooped, 8) good control for " no password" login, and 9) active code support.
In fairness, there were somethings Robert does not like about ssh: 1) relatively slow, 2) cannot select " no encryption" as an option even on secure networks, and 3) poor tty disconnect "feature" that requires ~. escapes (nested yet) to leave a job in the background from an ssh session.
| Sidebar One: No Password RSH Hints |
|
For more information on pasworldless logins, consult Passwordless SSH (and RSH) Logins on the Cluster Agenda. The brief outline below was taken from Beowulf Mailing list post by Joe Landman of Scalable Informatics Fri Jul 29, 2005. You will need to make sure your pam configuration enables rhost authentication. You will need this in your /etc/pam.d/rsh file
auth sufficient pam_rhosts_auth.so and you will need to either add " rsh" to your /etc/securetty, or simply remove that file. There are other good reasons to have the file, so you might wish to go with adding it rather than removing it. Then make sure your .rhosts are 600 mode and the nodes are listed in the .rhosts file.
chmod 600 ~/.rhosts Note: if you are trying to do this as root, you might need to use
auth required pam_rootok.so in your /etc/pam.d/rsh as well. Note: This is complex and painful to debug (many interacting systems). If you use ssh, it is much simpler. You create a shared key
ssh-keygen -t dsa (don't enter a passphrase for the key or you are going to run into prompting issues, just press enter). You will have a new key in ~/.ssh/id_dsa.pub . Copy this key to all the machines you wish to log in to without passwords. Append it to the ~/.ssh/authorized_keys file. Now you should be able to log in w/o a password. |
Robert went on to say that he thought, in most cases, the speed difference was negligible (you can search for some tests he did a few years ago showing the speed difference between rsh and ssh). He also pointed out that ssh is only used to start the jobs on remote nodes and that MPI/PVM is used once the program is running.
One of the strong features of ssh that Robert did not mention was the scalability of ssh. Due to its design rsh often has problems when the node count exceeds 256.
Trent Piepho responded that, in his opinion, for cluster jobs on a private network, the only bad things about rsh that really mattered was the lack of supported code and no environment passing. He also posted that when using Gigabit Ethernet he found rsh/rcp to be about 4 times faster than ssh/scp depending upon the CPU. Robert thought that Trent's numbers, while interesting didn't have a big impact on most applications because the actual traffic over ssh/scp was fairly small.
Andrew Cater then added some comments to Roberts first post. In particular, he said passing the environment, being able to port forward or tunnel, and intrinsic X11 were very important reasons for not using rsh. He also thought the authentication was good because once it's configured you don't need to update it despite account password changes.
Jakob Oestergaard posted that he thought MPI itself was vulnerable because of the lack of network security. He thought that the lack of environment passing, intrinsic X11, and tunneling/port forwarding within rsh were all overcome by some simple scripting or were not needed for most clusters. Jakob said he used NFS and NIS for file access and authentication. He felt that on a private " trusted" networks these were very reasonable alternatives (he failed to mention that NIS can be a huge drain on your network resources and tax your NIS master as well). He did mention that having frozen code was not such a bad thing for rsh because it works across many platforms seamlessly. Jakob concluded that he still preferred rsh for his closed private network with trusted users.
