rlogin and rsh
Dominic Baines
rdab100@hermes.cam.ac.uk
Sat, 26 Sep 1998 03:21:15 -0400
Call me paranoid but I go even one step further and add a firewall to restrict
access to
the server node as well so that only admin users etc can get to the cluster.
External NIC on this machine has institution IP, internal NIC has private IP and
I use IP Masquerading and a proxy to 'protect' the clusters.
Currently jobs only posted that way but looking at devising a semi/automated
batch process.
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.
I'd have said that this was the most sensible choice if you have 100% control of
whocan get at the cluster nodes, or if this was all they were used for. However,
some clusters have
now being built that use teaching labs and other similar public facilities where
consoles either need to be available for a 'normal' user during a cluster's
existence or
where the node needs to be used by another user. My first 'real'
cluster was a whole lab full of workstations where users logged into the nodes
and
used them normally. The second was a small room of linux fileservers. In both
cases computes
took a hit every now and then whilst this occured but at least I had the
use of a cluster until I could afford my own.
> 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.
Kind of a firewall then but wouldn't it be better for the server to place this
security elsewhere ?
> 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.
Unless they can or have to be used as described earlier.
> 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.
If you have no choice but to use nodes that can be accessed directly I feelyou
may already be expecting a hit in performance and have to accept that.
Unauthorised reboots would be a major risk but there are ways around that.
In that case the suggestion to use ssh is not a bad one is it ?
Dominic Baines
>
>
> Jacek
>
>
> First, use ssh instead of rsh.
>
> Then, if you want to access the user node as a human, create an
> identity
> and use ssh-agent to connect to the various machines.
>
> If you are looking to use the connection for running commands,
> create an
> identity with no passphrase, and then restrict the commands the
> identity
> can run via the .ssh/authorized_keys.
>
> Much safer than rsh.
>
> Some may complain about the performance penalty incurred by using
> ssh,
> however you can shut off the connection encryption and just use the
> authentication features as well.
>
> You can also do host based authentication a-la rsh which is much
> more
> secure than just .rhosts authentication.
>
> C=)
>
>
> --------------------------------------------------------------------------
> There is hardly a thing in the world that some man can not
> make a little worse and sell a little cheaper.
>
> --------------------------------------------------------------------------
> Caskey <caskey*technocage.com> ///
> pager.818.698.2306
> TechnoCage Inc. ///| gpg:
> 1024D/7BBB1485
>
> --------------------------------------------------------------------------
> I didn't fight my way to the top of the food chain to be a
> vegetarian.