To avoid connection issues while performing tasks, all the remote servers that have to be managed by Ansible need to be prepared to accept password-less ssh connection for the Ansible user. This preparation consists of configuring an Ansible user that will be typically used to run any Ansible task in all your infrastructure, and copying the user ssh public key on your remote servers.
In my lab the Ansible user is called user and I have two managed hosts named server1 and server2.
|Ansible User||Ansible Controller Machine||Ansible Managed Hosts|
|user||Server1||Server1 & Server2|
When running commands on the managed hosts, Ansible uses the same user account as the local user (the Ansible user), which means that Ansible will ssh to the remote managed servers using this user. The point here is to remember that Ansible need to ssh to the remote host to perform the task it is supposed to do.
Consequently, before being able to manage your remote hosts, you will need to have the same Ansible user created in all your managed hosts, generate its ssh keys and copy its public key to your managed servers. The end result would be to able to ssh to our remote hosts without providing a password.
Let’s make server1 and server2 ready to be managed by Ansible.
Generating the ssh keys
Use the ssh-keygen command to generate the public/private key pair on your Ansible controller. While generating the keys, you can choose to secure the key pair with password. This will prompt you to provide the password each time you’re using your keys to access to the remote host. Because this is lab is for training purpose, we can have a blank password by pressing Enter twice while we are asked to provide the passphrase.
[user@server1 ~]$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: SHA256:zW11t+PBC299H9YRgyM8Apj0vWO6kgnMrY6mUfMkrx8 firstname.lastname@example.org The key's randomart image is: +---[RSA 2048]----+ | ..o. | | o. o . . | | . o + o.oo| | oo.o.o.=| | * o S+o o. * | | . X . o .. + B| |. E o. B+| | o.o = . o +| |+.oo. .. .| +----[SHA256]-----+ [user@server1 ~]$
Copying the ssh public key to managed host
Next, we’ll have tp copy the public key to any host that need to be managed, using the ssh-copy-id commad
[user@server1 ~]$ ssh-copy-id server1 /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys user@server1's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'server1'" and check to make sure that only the key(s) you wanted were added. [user@server1 ~]$ ssh-copy-id server2 /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys user@server1's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'server2'" and check to make sure that only the key(s) you wanted were added.
Testing password-less ssh connection to managed host
Let’s test now to ssh to the hosts and check that no password is prompted
[user@server1 ~]$ ssh server1 Last login: Sun Jul 8 17:13:44 2018 from server1.contoso.local [user@server1 ~]$ logout Connection to server1 closed. [user@server1 ~]$ ssh server2 Last login: Sun Jul 8 17:13:59 2018 from server1.contoso.local [user@server2 ~]$ logout Connection to server2 closed.
Working now without any issue and our remote servers are prepared for ssh password-less connection. Note that you will do this for any server that need to be managed in your infrastructure. In virtual environment, you could use a preconfigured VM template that already has the public key copied, thus, all your new deployed VMs will be already configured.