[chef] Re: Re: Chef-vault: Unable to read passwords

["Moser, Kevin" < >]

There are only two hard things in Computer Science: cache invalidation and
naming things --Phil Karlton

Ha, seriously though not sure about when/why that value got named that but
I suspect it has something to do when the "users" endpoint was added.
Someone else probably has more history on it then I!  :-)

Kevin

On 12/2/13 12:02 PM, "Steffen Gebert" 
<
 >
 wrote:

>> I expected such a misunderstanding about clients and users on my side.
>>
>> What I didn't know (but think to have learned now): I don't need a
>> client for my workstation, but I should use a user (and only a user)
>> instead!?
>
>But.. why is the setting then called client_key? :-/
>
>Steffen
>
>
>On 02/12/13 20:45, Steffen Gebert wrote:
>> Hi Kevin,
>> 
>> yes, exactly. Thanks for your explanations!
>> 
>> I expected such a misunderstanding about clients and users on my side.
>> 
>> What I didn't know (but think to have learned now): I don't need a
>> client for my workstation, but I should use a user (and only a user)
>> instead!?
>> 
>> Yours
>> Steffen
>> 
>> On 02/12/13 17:57, Moser, Kevin wrote:
>>> Hi Steffen!
>>>
>>> This is a classic case of how the users and clients are stored for
>>> authentication.  They are actually different entities in the chef
>>>server
>>> and as such each has it's own public/private key pair for
>>>authentication.
>>> This is because users are not just for the webui, they are also used
>>>for
>>> knife access.
>>>
>>> What is happening here is that when you do a knife encrypt
>>>create/update
>>> --admins this tells chef-vault to look for a user with that name.
>>> Therefore your commands below are encrypting for the user "user1" but
>>>you
>>> are using the private key of client "user1" which does not match and
>>>hence
>>> you get the OpenSSL error.
>>>
>>> You have a couple options here:
>>>
>>> 1. Do not have clients and users with the same name, this can cause
>>> confusion like you are seeing
>>> 2. Use the private key of the user1 user on your box, then your
>>> public/private key pairs will match
>>> 3. Delete the user1 user and only use the client, to do this you would
>>> want to create a client/node pair called user1 and instead of using
>>> --admins, use --search "name:user1"
>>>
>>> In the next version coming soon chef-vault will first look for a user
>>> named what is given in --admins, if it can't find a user it will then
>>>look
>>> for a client named that.  This eliminates the need to create a node and
>>> client named the same and lets you still user --admins, instead of
>>> --search.
>>>
>>> Hope this clears it up!!
>>>
>>> Kevin
>>>
>>> On 11/27/13 12:13 PM, "Steffen Gebert" 
>>> <
 >
>>>  wrote:
>>>
>>>> Hi,
>>>>
>>>> I have the problem that I can't read my secrets with chef-vault (on my
>>>> workstation, but it works on nodes).
>>>>
>>>>> $ knife encrypt create secrets test '{"test":"foo"}' --admins user1
>>>>> --mode client
>>>>> $ knife encrypt update secrets test '{"test":"foo"}' --admins
>>>>> user1,user2 --mode client
>>>>> ERROR: OpenSSL::PKey::RSAError: padding check failed
>>>>> $ knife decrypt secrets test 'test' --mode client
>>>>> ERROR: OpenSSL::PKey::RSAError: padding check failed
>>>>
>>>> I'm not sure, what's the reason, but it seems to use a different key
>>>>for
>>>> encryption than for decryption? The same happens for another
>>>>colleague.
>>>>
>>>> `knife client show user1` and `knife user show user1` report different
>>>> public keys. Could this be the reason? Why has the user a public key
>>>> (thought it's only for logging into the webui).
>>>>
>>>> Thanks for your help
>>>> Steffen
>>>>
>>>
>>>
>> 
>> 
>> 
>
>