Regarding the debate about rsh'ing and rlogin'ing into systems as root:

There is a subtle difference between the two commands 'rsh' and 'rlogin'.
With rsh you *have to* already have been authenticated by the system you're
rsh'ing from.  The general idea is that you trust a set of systems to have
the same level of security, and you can "travel" freely within the set with
the privileges aquired at one of them. (All of course regulated by entries
in /etc/hosts.equiv and $HOME/.rhosts).  With rsh you can execute a command
on a remote machine as 'yourself' or as a different user *if* the
permissions are set up appropriately.  The security of the site relies on
the proper setup of the {.r,}hosts{,.equiv} files.  You can not (I think)
get access to accounts that isn't set up this way, i.e. you cannot use rsh
to authenticate yourself with a password in order to 'su' into some
suitable user id.

However, you can do this with the rlogin program.  You can perform an
rlogin to a completely alien system and try to guess passwords and
accountnames.  Thus, the rlogin program used in this manner is much more
similar to an ordinary telnet session than to the rsh command.  The problem
is that rlogin tries to be a bit of both. BTW, has anyone else spotted the
following statement in rlogin(1)->BUGS:
     Rlogin will be replaced by telnet(1) in the near future.

The way I think it should work is as follows:
rsh - same as today.  If you set up hosts.equiv or .rhosts you'd better know
      what you're doing.....
telnet - same as today.

rlogin - (if not replaced by telnet) if there is a matching entry in either
         hosts.equiv or the appropriate .rhosts file, allow the login to
         proceed. I think that this should also apply to uid=0 accounts.
         As has been pointed out there isn't much gained by disallowing
         these rlogins when the *sh -i trick will do it for you.
	 OTOH, if there are no matching entries in any of the appropriate
         files, and hence a password is needed, switch to telnet/login
         strategy, i.e. check for secure ttys, correct passwords etc.

This is only my 0.13NOK worth of thougths. (special offer, today only! :-)

					-jarle
----
"The only truly secure system is one that is powered off, cast in a
 block of concrete and sealed in a lead-lined room with armed guards --
 and even then I have my doubts."
				-- Eugene H. Spafford