I want to be a ...

I'm working on the small project which touches multiple cloud-based hosts across multiple providers. And this is a good chance to refresh your knowledge on how to handle various connections with Red Hat Ansible.

Let's see how you control the connection. There are a few ways:

• By default, Ansible would use your current user id and public RSA key to establish a connection with the remote target. You can spend some time an create new accounts for all your providers, or you can go with the next option
• User remote_user for plays or --user parameter for ad-hock commands. Ansible would try to connect with the provided user name. It's quite similar to the command ssh username@host.name.com
• If you have all different SSH users for your hosts (as in my case), you can modify your inventory and add variable ansible_ssh_user. The example below shows you how to use it.
• Ansible allows you to run a play or single task with an escalated privilege. Just add become  clause or --become for ad-hoc command
• If you need to execute a command as a non-root user, pair become with the become_user ( --become-user for ad-hoc) to specify desired user name

Let's take a look at my inventory excerpt to illustrate my topics:

---
all:
 vars:
   ansible_ssh_user: opc
 children:
   test-ready:
     hosts:
       host1.cloud.prj:
        ansible_ssh_user: ec2-user
       host2.cloud.prj:
       host4.cloud.prj:
       host5.cloud.prj:
        ansible_ssh_user: oracle
   not-ready:
     hosts:
       host3.cloud.prj:
        ansible_ssh_user: root
...

The first ansible_ssh_user says that opc is a remote user for all the hosts. Few lines down, you may see that host1 overrides global value with ec2-user. The same declaration happens for a few other hosts.

As usual, everything comes with a price. User id from inventory overpowers remote_user or ad-hoc keys, and you should use become_user instead. The output below illustrates the difference.