Interesting idea. I've been looking at getting puppet integrated into
our infrastructure as it is. I have a server built, but haven't had
time to fully delve into it what with all of our other stuff we're
working on.

-Mathew

"When you do things right, people won't be sure you've done anything
at all." - God; Futurama



On Tue, Nov 1, 2011 at 10:26 PM, Christopher R Webber
<[email protected]> wrote:
> A bit of a homebrew idea but you could use extlookup in puppet (I am sure 
> there is an equivalent way to do this in chef) to get the hash from a 
> somewhere and the password itself is stored in a locker of some sort. Once 
> the password has been access via the locker there is a "fuse" and when the 
> fuse expires, it changes the hash that is delivered via puppet. With a backup 
> mechanism storing an encrypted bundle somewhere offsite and the key in a safe.
>
> -- cwebber
>
> On Nov 1, 2011, at 19:11, "Mathew Snyder" <[email protected]> wrote:
>
>> "One use" is probably misleading. We have a requirement by our
>> contracting agency to expire ALL passwords every 60 days. This
>> includes service/application accounts and root. We are still working
>> out how to do this, but it seems that we have found a reasonable
>> compromise that is more commonly used (at least for root access). That
>> is to simply change the root password once it has been accessed in
>> whatever method it is stored (printed on paper and stored in a safe or
>> an app similar to KeePass, for example).
>>
>> We do not allow root login remotely (SSH is our only enabled remote
>> method). root can only log in via the console. Should anyone try to
>> simply su to root, its password is required. sudo is not configured
>> for the target accounts password so each user's password is used for
>> that.
>>
>> Ideally, I would like something that enforces changing the password
>> once it's been accessed rather than simply marking it as used and an
>> entirely new entry be made which is what KeePass does with its TANs.
>>
>> Individual user accounts are configured to expire using chage which
>> meets that requirement in a simple manner. However, as we also have no
>> need to access root directly except in the case of emergency, using
>> chage sets an unnecessary requirement to log in regularly to every
>> server just to change the password every 60 days. Hence, the desire
>> for what I can't think of any other way to describe except as "one
>> use".
>>
>> I'll take a look at that serverfault question first. Thanks, Matt. As
>> for the two-factor options, while we are required to have one in place
>> for certain things such as VPN access, we aren't required to have it
>> for server access and it would simply be too much overhead to deal
>> with on our little team. Thanks for the suggestion, though.
>>
>> -Mathew
>>
>> "When you do things right, people won't be sure you've done anything
>> at all." - God; Futurama
>>
>>
>>
>> On Tue, Nov 1, 2011 at 9:42 PM, Edward Ned Harvey <[email protected]> 
>> wrote:
>>>> From: [email protected] [mailto:[email protected]]
>>>> On Behalf Of Mathew Snyder
>>>>
>>>> I'm trying to find a suitable password management application. The
>>>> primary need is to allow for one-use passwords for root. I installed
>>>
>>> How does one implement single-use passwords?  There must be some kind of
>>> application you installed that regularly changes the root pass or something.
>>> They must have some way of securely communicating to some strictly
>>> authorized users what their one-time-use password will be this time.  How
>>> does the solution not avail itself naturally through this process?
>>>
>>>
>> _______________________________________________
>> Tech mailing list
>> [email protected]
>> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
>> This list provided by the League of Professional System Administrators
>> http://lopsa.org/
>
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to