managing user accounts without NIS
nmcfadye at mae.carleton.ca
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
> 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.
> 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
What about using the new Intel 100+ S NIC which uses IPSec?
Mech & Aero Eng.
More information about the Beowulf