managing user accounts without NIS

[Robert G. Brown]

On Sun, 21 May 2000, dwight wrote:

> Donald Becker wrote:
> 
> > On Sun, 21 May 2000, dwight wrote:
> >
> > > Victor Ortega wrote:
> > >
> > > > NIS and NFS are insecure and incur performance penalties.  I'm looking
> > > > for better alternatives.  My idea of setuid-root wrappers (using rsync
> > > > for distribution of relevant files) already provides a more secure,
> > > > high-performance, high-availability alternative; I just want to make
> > > > sure that there isn't something better out there already, and that I'm
> > > > not overlooking some potential security hole.
> > >
> > > Just using rsync per se might well subject you to a man-in-the-middle
> > > attack, or a spoofing attack. ssh/scp would be a better tool.
> >
> > An important element of Beowulf clusters is that they have a private,
> > protected internal network.
> 
> Agreed; but security seems to be an issue with his setup.

> > 'Ssh' imposes a large performance burden for its security.
> 
> I agree if you're talking about using ssh for all your connections; but it's not
> not that big of a deal if one is simply using scp to copy over /etc/[passwd, shadow].

A lot of this has been hashed out on the list before.

We (like many other sites) have moved to use ssh "only" as the default
shell within the department (including both inside and out of all
beowulfish clusters).  In practical terms, there are no user-noticeable
delays associated with using ssh.  Using the search engine to go through
the list archives (thanks dwight!) I was able to retrieve the following
post by Dave Hart:

  I ran NAS Parallel Benchmarks with rsh and with ssh and found less
  than 1% difference, IIRC. And since ssh is SOP . . .

so even abusing ssh to the extent of using it to run parallel code per
se the additional overhead is pretty much negligible.  As a basis for
cron-driven rsync tasks it is totally negligible.

Both rsh and ssh are high overhead to begin with (forking a shell is
pretty high overhead period). The bulk of ssh's additional overhead is
associated with establishing and authenticating the connection itself,
which is really a pretty wise use of compute cycles.  

The default running cryption (idea) is fairly lightweight for speed and
relies heavily on the passing of "good" keys at the original handshake,
although more expensive algorithms can be selected for very sensitive
data (at correspondingly greater overhead cost).  On a beowulf it can
optionally be used with no running traffic encryption (set Cipher to
"none" with -c none) to reduce the marginal cost in overhead to
practically nothing while still retaining the benefits list below.  Even
doing nothing and using the default adds a pretty much irrelevant
burden for "occasional" tasks.

Here is a short list of reasons to use ssh instead of rsh, even "inside"
a beowulf:

  a) rsh is an obsolete protocol.  It has been around for a LONG time
and unfortunately is nearly frozen in its development.  Consequently one
has to expect the bulk of any future developmental and improvement work
to occur in something being actively developed, like ssh.
  b) ssh is much more secure.  man-in-the-middle, X-based attacks, and
plain old net snooping are effectively shut out.  Hosts as well as users
are effectively authenticated.  Access can be controlled a variety of
ways (or combinations thereof) instead of just one or two.
  c) the marginal cost of using ssh instead is small (order of a few
percent) and getting smaller as everything continues to get faster.
  d) ssh can automatically compress/decompress the transmitted stream.
[rsync uses compression transparently and has the further advantage of
only sending files that need to be sent.]  Since file copies are
frequently network I/O bound, this can save far more time than ssh
costs.
  e) ssh forwards a variety of connections (e.g. commonly X, but also
arbitrary TCP/IP ports).
  f) ssh manages the enviroment better than rsh, in particular DISPLAY.
With ssh, xrsh is no longer necessary as ssh works better than xrsh ever
did.  However, many other environment variables are also passed.  The
most important feature of ssh for beowulf users is "/etc/environment"
which can be used to manage key environment variables such as PVM_ROOT
for all users provided that ssh is used as the remote shell for PVM.
  g) Even on a beowulf, one should be using ssh to access the head node
(which is usually on a PUBLIC network.  At that point, it becomes
administratively easier to use ssh everywhere throughout (as DIFFERENCES
in configuration are the major administrative cost), with the additional
benefit of being able to use all of the other advantages (b-f) to tunnel
through the head node "directly" to an internal node from any host on
the outer LAN.  With ssh, "all" hosts outside the beowulf can become
"head nodes" in a sense, while allowing the head node to become a
firewall indeed and allow ONLY sshd-based access to the interior.

Even ssh could be improved.  For example, it would be nice to have
control of a list of environment variables to be passed, instead of
having to work with a fixed list of built-ins (one of the main flaws of
rsh from time immemorial has been that it pretty much only passes TERM).
Since ssh is actively under development, there is a real chance that
suggested improvements will make it into the tool.  I fully expect that
in September when the RSA patent expires, a lot of distributions will
start to make ssh the default remote shell and rsh will quietly sink
into oblivion.

    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