installation help needed ...newbie

[Robert G. Brown]

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