rlogin and rsh

[Robert G. Brown]

On Fri, 25 Sep 1998, Jacek Radajewski wrote:

> Sorry, but I disagree with you.  My security model for Beowulf is to relax
> security as much as possible within the cluster, but concentrate on
> potential security threats coming from outside.  My master node (node which
> connects the cluster to the outside world) takes care of the security for
> the whole cluster, by running TCP wrappers, and kernel level packet filters.
> If for some reason an intruder gets through this security, and takes over
> the master node, then they already have all they can possibly get ; hence
> its silly to protect the dumb compute nodes.  The other issue is as you said
> performance, and this is the major issue in high performance computing.  In
> most cases there is absolutely no reason to use ssh within the cluster, and
> many reasons NOT to use it.
> 
> Jacek


Accepting that your gateway/firewall node in an isolated configuration
should be where your security efforts should lie (so presumably you do
run ssh-only connections into this host from the OUTSIDE, right:-)
what are the performance issues here?  The total marginal CPU or
network bandwidth expended on a task instantiation via remote ssh from
the master across the set of nodes vs an instantiation via rsh is
almost certainly totally negligible relative to the CPU expended on
the tasks themselves.  Surely you don't actually use the ssh to
mediate "IPC's" between the master and slave nodes.  I think
performance is not an issue here.

Although I don't have a strict isolation model for our beowulf (it's
on a switch, not inside a gateway) so I >>do<< have a security reason
for running ssh on the nodes, even if I ran the dedicated/headless
nodes in a gateway-isolated configuration I'd probably run ssh anyway
for several reasons:

  a) ssh is much smarter than rsh -- it can do things like
automatically handle remote X applications with correct setting of
DISPLAY and proper authentication.  I can run "ssh b3 xterm" to open
an xterm -- or anything else -- on host b3 in the beowulf without
having to mess with setting DISPLAY (or even caring what host I'm on
when I initiate the command).  

ssh even forwards DISPLAY for you -- I routinely slogin to b from a,
and c from b, and run an x command on c and have it display on a
without doing ANYTHING.  This is actually very useful WHEN you have a
gateway system -- you can login to the gateway host from your desktop,
login to an internal beowulf host from the gateway, run xterm or
procmeter and bam, it pops up on your desktop.  Cool way to
graphically monitor real-time performance on a beowulf host without
having to either sit at the gateway console and use xrsh or do a bunch
of setting of DISPLAY by hand or script.  Not that I don't love -- and
use -- bWatch as well:-)

  b) given that it is sensible to use ssh in the outermost network
(the one connected, one way or another, to the Internet and hence a
ping away from crackers in Kalamazoo) it is actually messier to
maintain two forms of rsh and the appropriate layers of /etc/hosts*
security than just one.  Administration time is expensive -- keeping
systems as homogeneous as possible is cheaper than differentiating
them needlessly.

  c) Since ssh and rsh behave slightly differently, a user has to
"shift gears" a lot when going from an environment where ssh is the
standard remote shell (as it should be on any Internet connected host)
to one where rsh is the shell.  I do this very occassionally, and
constantly bollix up things like a) when I find myself stuck with
"only" rsh.

I personally would advocate the complete abandonment of rsh.  The
number one avenue for crackers into our department network over the
last ten years has been password sniffing, at a ratio of something
like five or more sniffs to one "sophisticated" crack (via, e.g. buffer
overwrite or the like).  TCP-wrappers are totally futile as a defense
against sniffing -- the ONLY defenses that I'm aware of are
bidirectional encryption (cheap) or SecureID (the little cards that
change your passwd every five minutes, which are quite expensive).

We ONLY provide ssh as an internal version of rsh and we're actively
encouraging users to come in ONLY with ssh from faraway sites (where a
lot of the sniffing occurs) and plan to make this formal policy and
shut down telnet and rsh access altogether as soon as we can be 95%
sure that all our offsite faculty and students have access to ssh.
We'll probably have a firewall host set up for rsh/telnet access, but
users will have to change their passwd and endure restricted
privileges if they come in through the firewall.  The daily "cost" of
ssh even on a workstation where a lot of remote shell activitiy occurs
is on the order of a few minutes, at MOST, a day, and will diminish
still further as CPU's continue to get faster.  A small price to pay
for peace of mind (or if you want to be more concrete, for one or two
less cracking incidents a year with their VERY REAL costs in human
time and lost productivity).

   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@phy.duke.edu