installation help needed ...newbie

[rweidman at watson.chemical.missouri.edu]

Well my 2 cents on the rsh vs ssh issue is if you are on a protected
network, rsh is much mush easier to configure and use with a cluster.

</end 2 cents>

On Sat, 9 Mar 2002, Robert G. Brown wrote:

> On Fri, 8 Mar 2002, Donald Becker wrote:
> 
> > With 'rsh' there are many opportunities for permission problems.
> > Are you trying to run 'rsh' as root, or as a regular user?
> > Do you have the same set of users on all machines?
> > Do you have a ~root/.rhosts files as well as /etc/hosts.equiv?
> > (And there is probably something in the new xinetd that could cause
> > problems as well.)
> > 
> > I perceive that the community consensus is that 'ssh' should replace
> > 'rsh'.  It has substantially more start-up overhead, but handles the
> > environment much better.  It would be possible (and easier) to improve
> > 'rsh', but people seem to feel that it's flaws are fixed-in-stone
> > semantics.
> 
> They are not really fixed in stone, but they are fixed in man page,
> custom, and many, many implementations.  Five years ago one could have
> fixed rsh, but at this point any fix of rsh would necessarily reinvent
> most of ssh.  It is clearly desirable to have just one standard remote
> shell program to learn to install, configure, use, fix, and hence a
> "standard" remote shell pretty much has to be ABLE to do the encryption
> and machine and user-level authentication that are required on a WAN.
> Then there is (as you note) debugging (ssh -v), ssh's handling of the
> environment (still not perfect but rsh pretty much "doesn't" and
> something is better than nothing), and its lovely port forwarding
> capability.
> 
> It might not be so difficult to reinstitute "none" as a possible
> user-selectable cipher spec in ssh2 (which would reduce or eliminate the
> runtime encryption overhead) and to implement a flag which basically
> bypasses the host and user authentication components of ssh to reduce
> its startup cost while still keeping its other desirable features.  By
> leaving the enabling of these capabilities in any particular connection
> environment in the hands of systems people in e.g.  sshd.config,
> sysadmins could still prohibit the use of none and the bypassing of
> authentication in connecting clients, while a beowulf admin could
> install sshd configured to be as promiscuous (and relatively fast) as
> rsh.  Some people might scream a bit since if people CAN set a thing up
> to be insecure, some people WILL set it up to be insecure when they
> shouldn't, but as long as the default installation was secure and one
> had to learn a fair bit in order to reconfigure at all, it might remain
> in acceptable bounds.
> 
> But yes, I'd rather use ssh right out of the box than a "fixed" rsh,
> even on a protected network, and Duke has basically banned the use of
> rsh on any network that goes across the campus backbone to campus
> systems for obvious reasons.  ssh is more expensive than rsh, but unless
> one is running a LOT of ssh's, the difference is hardly noticable.  I'd
> argue that if one is using rsh for "lots of connections" (as some sort
> of serious network layer instead of just a way to facilitate the
> sporadic execution of remote tasks) in the first place, one probably is
> doing something the wrong way anyway and should consider reengineering
> the task.
> 
>    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
> 
> 
> 
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>