By default, Ansible uses SSH to connect to managed nodes (e.g. target systems).

This can be changed to some other protocol. However, assuming you'll be using SSH, you must be able to make an SSH connection from the control node (that's the Ansible server) to the managed nodes. Before configuring SSH, it's best to first establish known hosts.

Known hosts

When making an SSH connection to a managed node, if the public certificate of the managed node (server1 in this example) is not listed in the /etc/ssh/ssh_known_hosts or /home/username/.ssh/known_hosts file on the control node, a prompt will appear stating The authenticity of host 'hostname (ip address)' can't be established, like this.

The authenticity of host 'server1 (10.115.55.189)' can't be established
DSA key fingerprint is BB37 83F2 5E3A 7A4C 6C84  F047 D97B DD4E 38BB 2082
Are you sure you want to continue connecting (yes/no)?

Typing yes and pressing enter will append the public certificate of the managed node to the /etc/ssh/ssh_known_hosts or /home/username/.ssh/known_hosts file on the control node. However, a much better option is to use the known_hosts module to permanently append the managed nodes key to your known_hosts file.

The ssh command (on Linux) can be used to determine if you are able to make an SSH connection from the control node to the managed nodes.

When using the ansible-playbook command, if the remote_user parameter is not included in the playbook, the user that invokes the ansible-playbook command will be the user that is used for the SSH connection. If the remote_user parameter is included in the playbook, the remote_user will be used for the SSH connection.

SSH has a couple different authentication method.

• Password authentication
• Public/Private key authentication

The SSH server will be configured with password authentication, passwordless authentication, or both. The ssh command with the -v (verbose) flag can be used to determine the authentication methods of the SSH server, which should return something like this.

debug1: Authentications that can continue: publickey,password

If you attempt to make a connection to a managed node and Ansible has not been configured for SSH, the following will most likely be displayed.

server1.example.com | UNREACHABLE! => {	
    "changed": false,
    "msg": "Failed to connect to the host via ssh: Permission denied (publickey, password).",
    "unreachable": true 
}

And this will be the play recap.

PLAY RECAP
server1.example.com       : ok=0    changed=0    unreachable=1    failed=0

Password authentication

If the SSH server is configured to accept password authentication, command line flag --ask-pass can be used to prompt for your SSH password when issuing an Ansible command. The --ask-become-pass flag is only needed if the playbook includes the become parameters. Or, you could configure the default hosts file with your SSH username and password.

However, both of these approaches are not ideal, as they use a clear text password. A much better solution is to use an encrypted password for SSH.

Passwordless authentication

If the SSH server is configured to accept passwordless authentication, and the managed nodes are a Linux distribution, and OpenSSH is being used on each managed node, the openssh_keypair module or user module can be used to create or update a users private key (such as id_rsa) and public certificate (such as id_rsa.pub). Then the authorized_key module with the --ask-pass or --ask-become-pass flag can be used (assuming OpenSSH on the managed node is configured to accept password authentication) to append the users public key to the managed nodes authorized_keys file. After this has been done, then passwordless SSH connections can be made to the managed node.

Gather Facts

By default, facts are gathered. The gathering of facts makes an SSH connection to each managed node. 

Note: Using gather_facts: false in your playbook will supress some, but not all, fatal errors. Using gather_facts: false is discouraged, as this only masks the underlying issue. Instead, you should identify the cause of the fatal error and take approprate action.

Here is an example of one possible fatal return. This error tells you the cause of the issue (host key checking is enabled and sshpass does not support this), and the solution (add this hosts fingerprint to your known_hosts file). Refer to our SSH known_hosts article for more details on the known_hosts file. You could also use the ssh-keyscan command to append the SSH servers public certificate to your known_hosts file.

fatal: [server1.example.com]: FAILED! => {"msg": "Using a SSH password instead of a key is not possible because Host Key checking is enabled and sshpass does not support this. Please add this host's fingerprint to your known_hosts file to manage this host."}