Some critics say that Ansible does not do enough to warrant its deployment in an enterprise. The initial deployment to the managed nodes is less than what Puppet and Chef require. Even minionless deployments of SaltStack require more configuration work than Ansible. In this post, we want to demonstrate an advantage of adopting Ansible related to the first deployment. When using passwordless SSH authentication, the great benefit is the lack of a prompt. But experienced I.T. professionals know that there is an initial prompt -- not for a password, but to confirm the fingerprint of the remote host. This prompt can be an ECDSA or RSA prompt. When a user enters yes, the hostname or IP address and MAC address are all inserted into a known_hosts file (in the /root/.ssh/ location on CentOS/RHEL). Thereafter authentication to the remote server is without prompts (for both passwords and for server "fingerprints").
This initial prompt may seem small, but for the types of tasks that Ansible is completing (e.g., pushing down configuration changes to hundreds of servers), it can be burdensome. The way to leverage Ansible and not be prompted when running a playbook against servers that have never had an SSH session from the Ansible server to the managed node, is to use these steps on the Ansible server:
cd /
find . -name ansible.cfg #this way you will find the example template
cd /path/To/The/FileAbove/
cp -i ansible.cfg /etc/ansible/ansible.cfg
vi /etc/ansible/ansible.cfg
#find the [defaults] section, make sure this stanza appears and is not commented out:
host_key_checking = False
#save the file
Now playbooks can run against managed nodes without ever being prompted for an interactive "yes." This configuration file is great because for non-Ansible tasks, the /etc/ssh/sshd_config file does not need to be modified. StrictHostChecking can still be enabled for other SSH tasks. Beware that the known_hosts file will be updated with the servers that Ansible's playbooks affect (so this pure Ansible file does have broader implications to the server). This known_hosts file can be deleted for security reasons. For experienced bash and Python users, Ansible's learning curve is not steep.