On Fri, Feb 05, 2016 at 03:48:02PM GMT, Joshua Smith wrote:
> On Fri, Feb 05, 2016 at 04:04:47PM +0100, Joerg Jung wrote:
> > > On 05 Feb 2016, at 08:33, Peter N. M. Hansteen <pe...@bsdly.net> wrote:
> > >
> > > I'm assuming I'm not the first to encounter this -
> > >
> > > the scenario is a group of admins who have so far run mainly Linux and
> > > some
> > Solaris,
> > > and who have a fairly well developed Puppet setup for maintaining among
> > other things
> > > local users for admins to log in and fix, running sudo as required. For
> > non-admin role
> > > users, LDAP (AD) is considered good enough, but that's out of scope here.
> > >
> > > The interesting part is when we start introducing OpenBSD machines to the
> > mix, and
> > > creating users with the password hashes from Linux or Solaris fails,
> > apparently because
> > > the hashes are not bcrypt hashes.
> > >
> > > I see two obvious solutions to this. Either
> > >
> > > 1) skip password logins, require key logins for all local users (they're
> > > admins after all), tackle any extra privilege needs via specific sudo or
> > > doas config, or
> > >
> > > 2) maintain a separate set of user definitions with bcrypt hashes for the
> > OpenBSD
> > > boxes in the puppet setup. Then supplement as before with sudo or doas
> > tricks.
> > >
> > > My next question is, what other workable options are there? When you found
> > yourself
> > > in a similar situation, introducing OpenBSD to an existing environment of
> > other
> > > unixes, what did you do? Are there other solutions out there, possibly
> > > with
> > more
> > > sophisticated approaches than the ones I've mentioned here?
> >
> > There is: 3) dynamically chose the pass hash string depending on OS.
> > Last time I used puppet was with 2.x release, so I do not know the exact
> > syntax,
> > but something like this should work:
> >
> > @user {
> > myuser:
> > comment => “my user”,
> > ensure = “present”,
> > password => case $operatingsystem {
> > OpenBSD: { “$2b$….” },
> > RedHat: { “$6$...” },
> > Solaris: { “...” }
> > }
> > }
> >
> > I do similar in Ansible, setting a dynamic variable “user_hash” to either
> > “blowfish” or “sha512”
> > depending on the OS, and the use this variable to choose the right hash
> > string
> > from an dict,
> > which looks like this:
> >
> > users:
> > root:
> > blowfish: $2b$...
> > sha512: $6$…
> >
> > …referencing it later (in loops), like this:
> >
> > user: name=root password=users[root][user_hash]
> >
> > > Good suggestions may merit a beverage of choice (within reason) at the
> > first
> > > possible opportunity.
> > > --
> > > Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> > > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> > > "Remember to set the evil bit on all malicious network traffic"
> > > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
> +1 for Joerg's suggestion, he beat me to typing it but we do something
> similar here. We have a "local_user" wrapper class that has some logic
> built in to determine the proper password hash to apply based on the OS
> and some other things.
I also use case statement for this and other, not necessarily
OS-dependant, bits.
Raf
