This tutorial focuses on Ansible’s remote_user directive which allows us to specify the user account on the remote machine(s) that executes the playbook tasks.
Prerequisites:
To follow along with this post, ensure that you have the following:
- Basic understanding of Ansible and YAML syntax
- An installed version of Ansible (version 2.9 or later)
- Access to at least one remote server where Ansible runs the tasks
- SSH access to the remote server(s)
Ansible Remote_User Directive
By default, Ansible attempts to connect to all remote hosts with the username of the control node. However, if that username does not exist on the target host, you can set a different user using the remtoe_user directive.
We can configure the remote_user directive at different levels, providing precise control over the Ansible deployments. For example, we can set the directive in individual tasks for a given play or as a global setting that can be used in all plays and tasks in the Ansible playbook.
Configuring the Ansible Remote_User
Let us discuss the various methods and techniques to configure the remote_user directive.
Setting the Remote_User in Ansible Config
The first location where we can specify the remote_user is the Ansible configuration file (Ansible.cfg) which is typically located in /etc/ansible/ansible.cfg.
If we define the remote_user value in this file, the value will be applied globally on all the tasks and plays unless it is explicitly overridden in places with higher precedence.
The following is a basic syntax on how to set the remote_user parameter in the “Ansible.cfg” file:
remote_user = linuxhint
In this case, we define the value of the remote_user to Linuxhint which we apply to all Ansible configurations (unless specified).
Setting the Remote_User in an Inventory File
The second location where we can specify the value of the remote_user is in the inventory file. This allows us to define a value for each host or group of hosts which is more flexible.
Remember that the specified value in this location takes precedence over the “Ansible.cfg” file.
The following shows a basic example on how we can define the remote_user inside the Ansible configuration file:
web1 ansible_host=192.0.2.1 ansible_user=linuxhint
web2 ansible_host=192.0.2.2 ansible_user=linuxhint2
We can also define it as a group variable in the inventory file as follows:
hosts:
web1: 192.0.2.1
web2: 192.0.2.3
ansible_user: linuxhint
Setting the Remote_User in a Playbook
The other level where we can configure the remote_user parameter is inside a playbook. At this level, the parameter’s value applies to all the tasks that are defined within that playbook. It overrides any specified value in the Ansible config or inventory files.
The following is an example that demonstrates how to define the remote_user inside an Ansible playbook:
remote_user: linuxhint
tasks:
- name: Ensure apache is at the latest version
ansible.builtin.yum:
name: httpd
state: latest
Setting the Remote_User in a Task
Finally, the last place where we define the value of the remote_user variable is inside a specific ask. At this level, the value will only apply to that particular task where the value is defined.
This always takes the highest priority, overriding the defined values in the playbook, inventory, and Ansible configuration file.
The following playbook example demonstrates how to define the remote_user inside a specific task:
remote_user: linuxhint
tasks:
- name: Ensure apache is at the latest version
ansible.builtin.yum:
name: httpd
state: latest
- name: Run a command as another user
ansible.builtin.command: whoami
remote_user: linuxhint_lower
As you can see, the second task uses the linuxhint_lower as the remote user rather than the one that is defined in the playbook level.
Conclusion
We learned the workings of the remote_user directive in Ansible. This directive provides a flexible way of controlling which user account is used to execute the tasks on the remote machines. By setting the value of the remote_user at different levels, we can easily tailor Ansible’s behavior to suit our environment’s security policies and requirements.
NOTE: To run a given command as a different user, check the “become” directive rather than the remote_user.