Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Mar 1999 14:02:39 -0500
From:      Coranth Gryphon <gryphon@intech.net>
To:        Andrew Hobson <ahobson@eng.mindspring.net>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, freebsd-security@FreeBSD.ORG
Subject:   Re: Kerberos vs SSH
Message-ID:  <36FA884F.B2554229@intech.net>
References:  <Pine.GSO.4.10.9903251409300.17330-100000@primrose.isrc.qut.edu.au> <199903250426.UAA68023@apollo.backplane.com> <kjzp51u1y6.fsf@computer.eng.mindspring.net> <199903251833.KAA00915@apollo.backplane.com> <kjg16ttnm1.fsf@computer.eng.mindspring.net>

next in thread | previous in thread | raw e-mail | index | archive | help
> At work we have about a hundred machines and we access them via
> kerberos.  Admins have accounts on all boxes.  If we need to add or
> remove a user, it's a bit of a pain to manually update the password
> file on every machine.
> 
> We're a bit concerned about doing it automatically, because if
> something goes wrong, /etc/passwd might be corrupted or nonexistant.
> I'm not a big fan of NIS.
> At work we have about a hundred machines and we access them via
> kerberos.  Admins have accounts on all boxes.  If we need to add or
> remove a user, it's a bit of a pain to manually update the password
> file on every machine.
> 
> We're a bit concerned about doing it automatically, because if
> something goes wrong, /etc/passwd might be corrupted or nonexistant.
> I'm not a big fan of NIS.

That 'doing something wrong' is always a concern, but very often the
only solution is one where things entail some risk. If you can reduce
that risk to being only "code is written properly", then that's about
the best you can hope for.

We have a similar setup. What we use for remote password maintenance
is actually three step process.

First, all login information is stored in a single secure repository
(we use a SQL database on a carefully monitored machine). A single
interace allows you to change the configuration information that
gets distributed from this central source. This could just as easily
be stored in flat files or by some other means.

Then we have a program that generates the correct /etc/* files based
upon information stored in the repository. This is a pretty straight
forward script, the results of which can easily be verified.
 
Finally, we use ssh/scp to distribute the generated files to the
correct machines.

If you can figure out how to represent the information you want to dist
(ie. the source datamodel), then the rest is fairly straightforward.

-coranth


---------------------------------------+----------------------------
 Coranth Gryphon  <gryphon@hway.net>   |  Work Phone: 561-912-2497
 Chief Architect, Hiway Technologies   |  #include <std.disclaimer>
---------------------------------------+----------------------------
              When all else fails, do the impossible.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36FA884F.B2554229>