I’m trying to automate the addition of chef nodes to the chef server.
Cloud-init is running a script that downloads an admin user’s pem file from
an S3 bucket, generates a new node’s json file and adds the node with the
knife command, ie:
knife node from file /tmp/somenewnode.json -c /tmp/knife.rb
That works fine. I can see the new node on the chef server. After that,
another script downloaded from S3 is creating /etc/chef/client.rb file for
the new node, like so:
ssl_verify_mode :verify_peer
log_level :info
log_location STDOUT
chef_server_url ‘https://chef01.prod.slicetest.com:443’
validation_client_name ‘chef-validator’
validation_key
’/etc/chef/validation_keys/validator-chef01.prod.slicetest.com.pem’
When I run the chef-client I get a message:
Authentication Error:
Failed to authenticate to the chef server (http 401).
Server Response:
Invalid signature for user or client ‘chef-validator’
What am I missing here? I’ve confirmed the validator key is correct. I’m
making sure to remove both the node and the client from the chef server
before running (as I know that having an existing client cert on the server
will break it). Is this something to do with the trusted_certs thing? How
is that supposed to work?
Doug.
–
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
On Monday, November 24, 2014 at 12:45 PM, Douglas Garstang wrote:
Authentication Error:
Failed to authenticate to the chef server (http 401).
Server Response:
Invalid signature for user or client 'chef-validator'
What am I missing here? I've confirmed the validator key is correct. I'm making sure to remove both the node and the client from the chef server before running (as I know that having an existing client cert on the server will break it). Is this something to do with the trusted_certs thing? How is that supposed to work?
Doug.
Either the key is wrong, the validator username is wrong, or your clock is skewed by more than 15 minutes from the server (though the error message should normally indicate the last one).
trusted_certs has nothing to do with Chef’s application level authentication. The only thing it does is add certificates to the root CA bundle OpenSSL uses to check certificate validity for SSL/TLS connections. The point of this is to make it simpler to use chef-client with SSL peer verification (cert checking) enabled if you use self-signed certs (which is many/most people running their own servers).
I don’t know if it works anymore but I wrote this knife plugin a while ago to check client keys: https://github.com/danielsdeleo/knife-plugins/blob/master/key_check.rb You run it from a working admin account and it compares the private key you have (which contains the public key) to the public key you can download from the server. You can accomplish the same with various openssl commands.
--
Daniel DeLeo
Thanks Daniel.
Can you confirm that the private key on the chef server at
/etc/chef-server/chef-validator.pem is what I should be using as a
validation key on the client side?
Douglas.
On Mon, Nov 24, 2014 at 12:56 PM, Daniel DeLeo dan@kallistec.com wrote:
On Monday, November 24, 2014 at 12:45 PM, Douglas Garstang wrote:
Authentication Error:
Failed to authenticate to the chef server (http 401).
Server Response:
Invalid signature for user or client 'chef-validator'
What am I missing here? I've confirmed the validator key is correct. I'm
making sure to remove both the node and the client from the chef server
before running (as I know that having an existing client cert on the server
will break it). Is this something to do with the trusted_certs thing? How
is that supposed to work?
Doug.
Either the key is wrong, the validator username is wrong, or your clock is
skewed by more than 15 minutes from the server (though the error message
should normally indicate the last one).
trusted_certs has nothing to do with Chef’s application level
authentication. The only thing it does is add certificates to the root CA
bundle OpenSSL uses to check certificate validity for SSL/TLS connections.
The point of this is to make it simpler to use chef-client with SSL peer
verification (cert checking) enabled if you use self-signed certs (which is
many/most people running their own servers).
I don’t know if it works anymore but I wrote this knife plugin a while ago
to check client keys:
https://github.com/danielsdeleo/knife-plugins/blob/master/key_check.rb
You run it from a working admin account and it compares the private key you
have (which contains the public key) to the public key you can download
from the server. You can accomplish the same with various openssl commands.
--
Daniel DeLeo
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
I'm horribly confused. I just got it to work, and the validation key I used
is NOT what's on the server at /etc/chef-server/chef-validator.pem.
Doug.
On Mon, Nov 24, 2014 at 1:03 PM, Douglas Garstang doug.garstang@gmail.com
wrote:
Thanks Daniel.
Can you confirm that the private key on the chef server at
/etc/chef-server/chef-validator.pem is what I should be using as a
validation key on the client side?
Douglas.
On Mon, Nov 24, 2014 at 12:56 PM, Daniel DeLeo dan@kallistec.com wrote:
On Monday, November 24, 2014 at 12:45 PM, Douglas Garstang wrote:
Authentication Error:
Failed to authenticate to the chef server (http 401).
Server Response:
Invalid signature for user or client 'chef-validator'
What am I missing here? I've confirmed the validator key is correct.
I'm making sure to remove both the node and the client from the chef server
before running (as I know that having an existing client cert on the server
will break it). Is this something to do with the trusted_certs thing? How
is that supposed to work?
Doug.
Either the key is wrong, the validator username is wrong, or your clock
is skewed by more than 15 minutes from the server (though the error message
should normally indicate the last one).
trusted_certs has nothing to do with Chef’s application level
authentication. The only thing it does is add certificates to the root CA
bundle OpenSSL uses to check certificate validity for SSL/TLS connections.
The point of this is to make it simpler to use chef-client with SSL peer
verification (cert checking) enabled if you use self-signed certs (which is
many/most people running their own servers).
I don’t know if it works anymore but I wrote this knife plugin a while
ago to check client keys:
https://github.com/danielsdeleo/knife-plugins/blob/master/key_check.rb
You run it from a working admin account and it compares the private key you
have (which contains the public key) to the public key you can download
from the server. You can accomplish the same with various openssl commands.
--
Daniel DeLeo
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
On Monday, November 24, 2014 at 1:08 PM, Douglas Garstang wrote:
I'm horribly confused. I just got it to work, and the validation key I used is NOT what's on the server at /etc/chef-server/chef-validator.pem.
Doug.
If you run knife client reregister VALIDATOR_NAME (or the equivalent HTTP API calls via some other means) then a new key is generated for the validator and the old one becomes invalid. I don’t think there’s a way that this can be fixed automatically, since the server doesn’t keep a copy of the private key.
My personal opinion is that the validator mechanism for creating new clients/nodes is overly error-prone and should only be used when you absolutely must have “self bootstrapping” behavior, for example when PXE booting or using AWS autoscaling and you’ve baked the credentials into your OS image. From your previous email, it looks like you’re creating node data from a script/program you’re writing yourself. If it’s an option for you, you might want to do something like the following:
knife client create -u ADMIN_USER -k ADMIN_KEY -f NEW_NODE_KEY.pem NEW_NODE_NAME
knife node create -u NEW_NODE_NAME -k NEW_NODE_KEY.pem # or other knife command/API tool
Then you need to copy the NEW_NODE_KEY.pem to the new machine and configure it with the correct NEW_NODE_NAME. The downside to this approach is that you need to protect NEW_NODE_KEY.pem from being disclosed to anyone/anything that shouldn’t have it, I think you can achieve this for s3 via IAM but I’m not 100% sure.
HTH,
--
Daniel DeLeo