Hello gentle people,
I think being able to register the output of commands/modules as host variables will be very useful.
I got this idea writing a playbook to do;
- create a root user key pair for a couple hosts
- authorizing the root user public key of all hosts to connect to all other hosts.
My approach is to use the ‘user’ module to create generate the key pair, then use the output
of the user module for each host as the key parameter to the ‘authorized_key’ module.
-
name: generate SSH key pair for root user
user:
name: root
generate_ssh_key: yes
ssh_key_comment: “{{inventory_hostname}}”
register: root_key
-
name: add authorized keys for root
authorized_key:
user: root
key: “{{hostvars[item][‘root_key’][‘ssh_public_key’]}}”
with_items: groups[‘allservers’]
Unless I am not using ‘register’ right. The above obviously failed because register can not be
associated with the host on which the module run. This will definitely be a good thing to have.
Any thoughts on my approach to generating and authorizing key pairs for all hosts?
Is the ability to register module output like a host variable useful or can such be accomplished by
other means?
“. The above obviously failed because register can not be
associated with the host on which the module run.”
I’m not understanding this part entirely, but I’d recommend authorizing keys for specific users and setting up sudo in general in that case.
For our own ansible infrastructure, this involves a list of users and their keyfiles, and then something like what’s below.
Checking your authorized keys into source control can be a good idea.
You may also wish to template the authorized_key file using a list of keys, rather than using the authorized_key module.
|
|
|
|
- name: create/managed authorized users
|
|
user: name={{ item.username }} groups=wheel append=yes
|
|
with_items: authorized_users
|
|
|
|
|
|
- name: remove unauthorized user accounts
|
|
user: name={{ item.username }} state=absent
|
|
with_items: unauthorized_users
|
|
|
|
|
|
authorized_key: user={{ item.username }} key=“{{ lookup(‘file’, item.key) }}”
|
|
with_items: authorized_users
|
Wonderful! Thank you.
“. The above obviously failed because register can not be
associated with the host on which the module run.”
For the above, say I run a command in a task on every host in a play. I was thinking it wil be nice to register the output of the command such that the
output of the command can be accessed as it run on the host in a later task.
In other words when the output of the command is registered, it can be saved along with the host variables for the remote host on which the command
run. This way at a later time we can always access the registered output using a syntax like ‘{{hostvars[hostA][result]}}’. For example
I’m not understanding this part entirely, but I’d recommend authorizing keys for specific users and setting up sudo in general in that case.
For our own ansible infrastructure, this involves a list of users and their keyfiles, and then something like what’s below.
Checking your authorized keys into source control can be a good idea.
You may also wish to template the authorized_key file using a list of keys, rather than using the authorized_key module.
Thank you for the The user + key file approach, and checking in the authorized_keys work great for authorizing users. However this gets complicated when you have hosts which carry out tasks on different hosts, such as a server rsyncing files to be backed up to a backup server. These tasks are generally scripted and so keys are usually passwordless. Committing these keys with your code means that anyone who gets access to your code, gets access to your servers.
This is why I will like to be able to generate the root key pair and authorize for all hosts it in a play. This way I do not have to worry about the storage of such a sensitive key potentially exposing my hosts.
If you’re on the development branch, we identified a bug yesterday where registered variables were not accessible via hostvars, which was a result of the new “Fact Caching” additions.
This is now resolved as of yesterday.
Can you let me know what Ansible version you were using and whether this resolves the problem?
I am on the development branch, and the ansible 1.8 (devel 1dc11c9752) release resolves the problem for me.
Thank you very much.