We use group membership and ³AllowGroups² in /etc/ssh/sshd_config
We define which group(s) can go on which machines in our puppet manifest
and let puppet enforce the ssh_config content accordingly.
For the machines not connecting to our LDAP server for authorization, we
tell puppet which users to create on which machines. It¹s still complex
but at least we don¹t rely on manual config based on an excel sheet.
Valère Binet [C]
IT Security Administrator
Kelly Government Solutions On-Site at the NIH
NIH / NIA / IRP
Tel : 410 558 8013
mailto: binetv@xxxxxxxxxxx
NCTS performance comments and survey at:
https://niairpkiosk.irp.nia.nih.gov/content/ncts-user-survey
On 6/4/15, 3:34 PM, "m.roth@xxxxxxxxx" <m.roth@xxxxxxxxx> wrote:
>Matt Garman wrote:
>> Our environment has several "classes" of servers, such as
>> "development", "production", "qa", "utility", etc. Then we have all
>> our users. There's no obvious mapping between users and server class.
>> Some users may have access to only one class, some may span multiple
>> classes, etc. And for maximum complexity, some classes of machines
>> use local (i.e. /etc/passwd, /etc/shadow) authentication, others use
>> Kerberos.
>>
>> With enough users and enough classes, it gets to be more than one can
>> easily manage with a simple spreadsheet or other crude mechanism.
>> Plus the ever-growing risk of giving a user access to a class he
>> shouldn't have.
>>
>> Is there a simple centralized solution that can simplify the
>> management of this? One caveat though is that our "production" class
>> machines should not have any external dependencies. These are
>> business-critical, so we try to minimize any single point of failure
>> (e.g. a central server). Plus the production class machines are
>> distributed in multiple remote locations.
>>
>> Any thoughts?
>
>I agree completely with your manager: nobody but the production admins,
>and the "system owners", should be allowed on the machine, unless you want
>to allow selected sr. people to be able to get on in the event that
>something that's just gone into production has just broken, to see if it
>can be a quick fix, or whether you need to roll it back.
>
>Likewise, neither developers nor "ordinary users" should be allowed on the
>q/a systems, which ought to be clones of production, with the exceptions
>of the new releases.
>
>I'm not sure whether "ordinary users" should be allowed on dev systems,
>unless they need to look in on what's going on.
>
>In a true professional environment, only the admins get to move things to
>prod; dev can promote in the VCS, and the testers can bring that in, then
>promote so that the admins can roll that out during a prearranged
>maintenance window.
>
>All of this is easily done. We have the organization-wide AD (sigh), which
>authenticates, and allows single sign-on, single password. Then there's
>authorization.... We have a large /etc/password, but if you're not allowed
>on, your shell is /bin/noLogin. <g>
>
> mark
>
>_______________________________________________
>CentOS mailing list
>CentOS@xxxxxxxxxx
>http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
