Ansible SSH Authentication

SSH key-based authentication is the security foundation upon which all Ansible operations rest. Understanding how it works — and how to configure it correctly — is not optional. This lesson explains the mechanics of public-key cryptography in practical terms, walks through key generation and distribution, and covers the privilege escalation configuration that allows Ansible to perform administrative tasks on managed nodes.

Why SSH Keys Instead of Passwords

Ansible can use password-based SSH authentication, but it is strongly discouraged in practice for three reasons: passwords cannot be stored safely in automation scripts, password prompts break unattended automation runs, and SSH keys are cryptographically stronger than any human-memorable password. Once you experience the seamlessness of key-based authentication, you will never want to type SSH passwords again.

How SSH Key Pairs Work

An SSH key pair consists of two mathematically linked files. The private key stays on your control node and must never be shared. The public key is placed on managed nodes. When Ansible connects, the managed node challenges the connecting client to prove it holds the private key — without ever transmitting the private key itself. This cryptographic handshake is both more secure and more convenient than passwords.

Generating an SSH Key Pair

If you do not already have an SSH key pair for Ansible, generate one:

ssh-keygen -t ed25519 -C "ansible-control" -f ~/.ssh/ansible_ed25519

Ed25519 is the recommended algorithm — it produces shorter keys than RSA while being more secure. The -f flag specifies the filename, keeping your Ansible key separate from other keys. The -C flag adds a comment for identification.

When prompted for a passphrase, you have two options:

• No passphrase (empty): Simpler for automation but less secure if the private key file is stolen.
• Passphrase protected: More secure; use ssh-agent to avoid entering the passphrase repeatedly.

For production environments, always use a passphrase and manage it with ssh-agent or a secrets manager.

Distributing Your Public Key to Managed Nodes

The public key must be added to the ~/.ssh/authorized_keys file on each managed node. The easiest way:

ssh-copy-id -i ~/.ssh/ansible_ed25519.pub ubuntu@192.168.56.11

This command appends your public key to the remote user's authorized_keys file. Repeat for each managed node. If ssh-copy-id is not available, copy the key manually:

cat ~/.ssh/ansible_ed25519.pub | ssh ubuntu@192.168.56.11 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

After distributing the key, test the connection without Ansible first:

ssh -i ~/.ssh/ansible_ed25519 ubuntu@192.168.56.11

If this connects without prompting for a password, key-based authentication is working correctly.

Configuring Ansible to Use Your Key

Tell Ansible which private key to use in your ansible.cfg or inventory:

[defaults]
private_key_file = ~/.ssh/ansible_ed25519
remote_user = ubuntu

Or in group_vars/all.yml:

ansible_ssh_private_key_file: ~/.ssh/ansible_ed25519
ansible_user: ubuntu

Privilege Escalation with sudo

Most administrative tasks — installing packages, managing services, writing to system directories — require root privileges. Ansible handles this through privilege escalation, typically via sudo. The relevant Ansible configuration:

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

Setting become = true in ansible.cfg makes every task run with sudo by default. You can also set become: true at the play level or task level in a playbook for more granular control.

For sudo to work without a password (required for unattended automation), configure your managed node's sudoers file:

ubuntu ALL=(ALL) NOPASSWD:ALL

Add this line by running sudo visudo on the managed node, or use a sudoers drop-in file in /etc/sudoers.d/.

Using ssh-agent for Passphrase-Protected Keys

If your private key has a passphrase, add it to ssh-agent at the start of your session:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/ansible_ed25519

ssh-agent stores the decrypted key in memory for the duration of your session. Ansible and SSH automatically use the agent, so you only enter the passphrase once per session.

SSH Known Hosts and host_key_checking

When SSH connects to a host for the first time, it displays a fingerprint and asks you to verify the host's identity. In automation, this interactive prompt breaks unattended runs. Two approaches:

For labs (acceptable): Disable host key checking in ansible.cfg:

[defaults]
host_key_checking = False

For production (required): Pre-populate the known_hosts file. This can be automated with ssh-keyscan:

ssh-keyscan -H 192.168.56.11 >> ~/.ssh/known_hosts

Try This: Full SSH Configuration Test

Run this sequence to verify your complete SSH configuration for Ansible:

ssh -i ~/.ssh/ansible_ed25519 -o StrictHostKeyChecking=no ubuntu@192.168.56.11 "sudo whoami"

If the output is root, your SSH key, sudo configuration, and privilege escalation are all working correctly. Ansible will behave identically to this manual test.

Summary

SSH key-based authentication eliminates passwords from the automation workflow while providing stronger security. Key pairs consist of a private key on the control node and a public key on managed nodes. Privilege escalation via sudo allows Ansible to perform administrative tasks. ssh-agent handles passphrase-protected keys in interactive sessions. Proper SSH configuration is the prerequisite for every Ansible operation in this course.