Ansible - 3 - 2 Demo ansible inventory

It is time to put the inventory to work. We start by manually SSH-ing from the controller to ansible-target-1, accepting the host key fingerprint, then logging out — that initial handshake stores the target's key in the controller's known_hosts file, which Ansible will reuse later. From there we create a small project folder and a custom inventory file inside it.

# inventory
target1 ansible_host=192.168.1.10 ansible_ssh_pass=osboxes.org

ansible -i inventory target1 -m ping

The ansible command runs an ad-hoc task on the named host. The -m ping module verifies that the controller can connect, log in and execute Python on the target. A successful run returns a green SUCCESS message — proof that controller and target talk to each other.

The classic SSH host key trap

  • Add a second host target2 in the inventory without performing the manual SSH handshake first.
  • Running the same ping command fails because the target's host key is not in known_hosts yet.
  • Two fixes exist: SSH into the new target once to accept the fingerprint, or disable host key checking in /etc/ansible/ansible.cfg by uncommenting host_key_checking = False.

Disabling host key checking is convenient in a lab but unsafe in production. The recommended approach is to deploy SSH public keys to every target and rely on key-based authentication, which removes the need for plain-text passwords in the inventory at the same time. For now we know how to declare hosts, run an ad-hoc command and recognise the most common SSH error — a strong foundation before diving into playbooks.

Summary

This lesson demonstrates how to create and configure an Ansible inventory file to manage target hosts. The instructor walks through setting up target servers with their IP addresses and authentication credentials, then validates connectivity using the Ansible ping module. The lesson addresses a critical issue when adding multiple targets: SSH host key verification failures and shows both the immediate workaround (manual SSH connection acceptance) and the configuration-based approach (host key checking), emphasizing that SSH key pairs are the recommended authentication method for production environments over password-based authentication.

Key points

  • Inventory files define target hosts with IP addresses and connection parameters (ansible_host, ansible_password, etc.)
  • The Ansible ping module validates connectivity between the control node and managed hosts before executing tasks
  • SSH host key fingerprint acceptance occurs when manually connecting to a new host for the first time via the control node
  • Host key checking can be disabled in ansible.cfg by setting 'host_key_checking = False', though this is not recommended
  • Production environments should use SSH key-based authentication (with ssh-keyscan or manual key acceptance) rather than password-based authentication for security
  • Multiple inventory entries must each have their host keys verified, either through manual SSH connection or by configuring Ansible to skip this verification

FAQ

Why did the ping test fail for the second target host?

The second target's SSH host key fingerprint had not been accepted on the control node. Unlike the first target, there was no prior manual SSH connection to accept and store the host key in the known_hosts file. Ansible requires this verification by default unless host_key_checking is disabled.

What are the two methods to resolve SSH host key verification failures in Ansible?

Method 1: Manually SSH from the control node to each target and respond 'yes' to accept the fingerprint, which adds the key to known_hosts. Method 2: Disable host key checking in the Ansible configuration file (ansible.cfg) by setting 'host_key_checking = False', though this is not recommended for security reasons.

Why is SSH key-based authentication preferred over password authentication in production Ansible deployments?

SSH key-based authentication is more secure than passwords, eliminates the need to store credentials in inventory files, provides better auditability through key management, and aligns with security best practices. Using SSH keys prevents credentials from being exposed in configuration files or logs.