Chef-vault: Unable to read passwords

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

Hi,

I have the problem that I can't read my secrets with chef-vault (on my
workstation, but it works on nodes).

anybody an idea?

Thanks
Steffen

On 27/11/13 21:13, 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

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" st+gmane@st-g.de 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

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" st+gmane@st-g.de 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

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" st+gmane@st-g.de 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

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! :slight_smile:

Kevin

On 12/2/13 12:02 PM, "Steffen Gebert" st+gmane@st-g.de 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" st+gmane@st-g.de 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