Robert G. Brown rgb at
Wed Sep 24 07:08:43 EDT 2003

On Tue, 23 Sep 2003, Trent Piepho wrote:

> On Tue, 23 Sep 2003, Robert G. Brown wrote:
> > > 
> > > About one order of magnitude slower, and a great deal more cpu time.
> > 
> > But still pretty much negligible, on a job intended to run all day.
> True, but what about interactive tasks?  Say I want to run uptime or netstat
> or lilo, or some other simple command on all the nodes of a 100 node cluster. 
> Doing it via rsh would take 3 seconds, via ssh 40.  That's a big difference
> when you are waiting for the results.

Ah, but that's why I wrote xmlsysd and wulfstat (or more practically,
why Erik Hendriks et al wrote bproc;-) Interactive task distribution and
monitoring is NEVER very efficient or lightweight when it runs through
an instantiated shell.

And sure, as I said, if you use ssh to distribute lots of small tasks
and want immediate results it isn't very good.  Mostly because of the
handshaking, I think -- I doubt that this is an encryption issue.  Here
is where one has to do the cost-benefit tradeoffs.  Duke more or less
prohibits the use of rsh on systems exposed to any sort of public
network because the cost of ANY sort of cracking incident is very high,
and very real.  On a firewalled cluster of course one could install it,
but I've seen cracking and data theft incidents at Duke WITHIN RESEARCH
GROUPS (one e.g. postdoc snooping wire data and root password, stealing
files, apparently exporting said files to friends back in Bulgaria in
his particular case to search for value).  

One could argue that if it is for use on YOUR cluster, architected
inside a protected network as a "true beowulf" and with only one user,
you can do what you like (and who could argue:-) -- from what Erik has
told me in years past, bproc isn't secure on the inside either, but the
presumption there is that "nodes" have nothing of value but immediate
data and the only point of access is the head node (these are guys who
think rsh is -- correctly -- heaviweight:-). 

In any sort of environment with trust boundaries or valuable data,
though, or where one might wish to export environment variables along
with the shell processes, using rsh enables those boundaries to be
fairly trivially violated by anyone with root/promiscuous mode access to
the wire itself (via e.g. a handy laptop).  ssh in that sort of
environment is just a form of due diligence.  sshd, too, is subjected to
intense scrutiny looking for buffer overwrites and exploits, while rshd
is not under the presumption perhaps that it is OBVIOUSLY not secure so
why bother?

At Duke we have made the decision to use ssh only, because of the
security issues, and use tools like xmlsysd to do the few tasks that we
might otherwise like to distribute in real time with a remote shell.  At
other institutions one might well choose otherwise.  YMMV, and we live
in a world of marvelous choices.

> > (less than all day).  And yeah, enabling rsh/rcp long enough to
> > facilitate the transfer might be easier/faster.
> I tried that first, but rcp barfed on the files larger than 2GB!

Hmm, sounds like an int counter in there somewhere...;-)

Seriously, one thing that might be worth TRYING is to request that the
openssh people restore a "none" encryption option on ssh/sshd, enabled
by /etc/ssh/*.config options so that local admins can disable it on open
networks.  I can't see why this would be objectionable to them, and it
would solve at least this half of the problem.


> _______________________________________________
> Beowulf mailing list, Beowulf at
> To change your subscription (digest mode or unsubscribe) visit

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

Beowulf mailing list, Beowulf at
To change your subscription (digest mode or unsubscribe) visit

More information about the Beowulf mailing list