rsh

Steven Timm timm at fnal.gov
Wed Sep 24 07:18:56 EDT 2003


Nobody has yet mentioned in this thread that there is an option
to run a kerberos-enabled rsh and do kerberos authentication,
and even DES encryption of your session traffic and data stream.
Obviously it's a bit slower than ssh but it is quite secure
and has solved our problems quite well.

Steve Timm


------------------------------------------------------------------
Steven C. Timm (630) 840-8525  timm at fnal.gov  http://home.fnal.gov/~timm/
Fermilab Computing Division/Core Support Services Dept.
Assistant Group Leader, Scientific Computing Support Group
Lead of Computing Farms Team

On Tue, 23 Sep 2003, Robert G. Brown wrote:

> On Mon, 22 Sep 2003, Jan Schaumann wrote:
>
> > Chris Samuel <csamuel at vpac.org> wrote:
> >
> > > On Wed, 17 Sep 2003 12:51 pm, masego-otlhe_segone wrote:
> > >
> > > > I have managed to install mpich v1.2.5.2 on my cluster of two nodes, but I
> > > > just realised that I cannot communicate with other hosts due to some rsh
> > > > setting that I need to do.
> > >
> > > To be honest I'd really suggest not using RSH and swapping over to OpenSSH
> > > instead.
> >
> > Why?  Most likely, ssh will introduce a non-negligible overhead in
> > encryption and/or compression.
>
> I'd actually say that it will introduce a negligible overhead in both
> those dimensions for most usage.  As in a few seconds (extra) to launch
> quite a few tasks.  Periodically I measure and post the numbers but can
> never remember what they are the next time this issue rolls around.
> However, they aren't horribly large in absolute terms, let alone
> relative ones, and are likely to be cumulatively signficant only on very
> large clusters for most tasks.
>
> With that said, for some usage patterns (spawning lots of very short
> tasks) they might impact signficantly even on small clusters (yes, the
> mandatory YMMV:-) , but for the more common spawning of lots of tasks
> intended to run >>a signficant amount of time<< (e.g. a day), the
> fraction of a second per task marginal cost associated with startup via
> ssh vs rsh is indeed negligible.  Even tasks where this isn't the case
> can usually be engineered so that it is (and should be).  If ssh isn't
> adequately efficient, chances are good that rsh is a (smaller but still
> significant) bottleneck too, since the latency differential is only
> about a factor of two or three IIRC, and should be scaled away by
> altering your task organization so that the parallel task runs a "long"
> time compared to startup time for any remote shell.
>
> The issue can also be avoided (as Josip notes) by using LAM or PVM,
> which spawn a daemon via ssh but subsequently start tasks without any
> shell-level overhead at all.
>
> Overall, given my sysadmin background, I tend to really dislike the idea
> of keeping rsh around at all and expect that one day it will be
> deprecated and just go away (in many environments this is true already).
> It is obsolete, insecure, and fairly stupid when it comes to managing
> the shell environment.  ssh has a lot of advantages compared to rsh
> aside from its security.  I personally wish they had left in the option
> to turn off encryption (AS an option) which one used to be able to do
> just to reduce the overhead still further on clusters while retaining
> its other advantages and features, but not unreasonably the ssh people
> decided not to so that foolish users couldn't turn it off by accident or
> design.
>
> In many environments, the time wasted by ONE successful password crack
> due to snooping is far, far greater than any number of rsh margins.
>
>    rgb
>
> >
> > To the OP: check your /etc/hosts.equiv and ~/.rhosts, as suggested by
> > rsh(1) and rlogin(1).
> >
> > -Jan
> >
> >
>
> --
> 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
>
>
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>

_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf



More information about the Beowulf mailing list