[RndTbl] Hey security guys!

[Robert Keizer]

I'll chime in with salt stack. Take a look, it has the ability to do what
you want, plus more.

Also, I use openssh-lpk on my systems, which allows the public key to be
looked up via ldap based in the user id.
On 2014-03-20 2:21 PM, "Sean Walberg" <sean at ertw.com> wrote:

> Use chef/puppet/ansible/fuckingshellscripts.org and distribute individual
> keys to the appropriate user accounts. Then you can manage
> keys/sudo/centralized auth much easier.
>
> Sean
>
>
> On Thu, Mar 20, 2014 at 1:38 PM, Kevin McGregor <
> kevin.a.mcgregor at gmail.com> wrote:
>
>> We have a pile of Linux servers here at work. We'd like to set up the
>> shared keys to simplify admin via SSH. Here's the thing (quoted from an
>> email I received):
>>
>> We are thinking of putting public/private ssh keys on all of our Linux
>> servers.
>>
>> The purpose of this is so that our central admin server can "do stuff' on
>> all of our servers without needing a password. We are wondering how far to
>> go for convenience.
>>
>>
>>
>> Below are restrictions that we can place on the key pair (there may be
>> others, but these are the ones of which I'm aware). Have a look at each
>> restriction and consider whether we should use the restriction or not.
>> Basically it would be most convenient to have none of the restrictions.
>>
>> ·         We can create a password on the key pair
>>
>> o   This would defeat the whole purpose of using the key pair to avoid
>> passwords
>>
>> ·         We can limit which user can run things on the target machine
>>
>> o   Most likely, we would install the public key for the user root
>> (therefore things would run as user=root)
>>
>> ·         We can limit what commands can be run on the target machine
>>
>> o   We would like to leave this wide open so we can run anything remotely
>>
>> ·         We can limit the source machine that can initiate remote
>> commands (ie - commands can only come from the admin machine)
>>
>> o   It would be nice to not have this limit as we could move the private
>> key onto other machines (eg a VM on your desktop) to be able to run things
>> remotely
>>
>> o   The downside is that if anybody gets the private key, they can do
>> anything
>>
>>
>>
>> Note that firewalls should prevent people from the internet trying to
>> connect to ssh.
>>
>> [Comments, anyone? - Kevin]
>>
>> _______________________________________________
>> Roundtable mailing list
>> Roundtable at muug.mb.ca
>> http://www.muug.mb.ca/mailman/listinfo/roundtable
>>
>>
>
>
> --
> Sean Walberg <sean at ertw.com>    http://ertw.com/
>
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20140321/c1280f92/attachment.html>