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

[Steffen Gebert < >]

> 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
>>>
>>
>>
> 
> 
>