managing user accounts without NIS

Tue May 23 14:29:14 PDT 2000

"Robert G. Brown" wrote:

> 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
>
> _______________________________________________
> Beowulf mailing list
> Beowulf at beowulf.org
> http://www.beowulf.org/mailman/listinfo/beowulf

What about using the new Intel 100+ S NIC which uses IPSec?

Neil McFadyen
System Administrator
Mech & Aero Eng.
Carleton University
Ottawa, Ontario