Agentless Architecture and SSH
Ansible's agentless model means the control node — the machine where you run ansible-playbook — connects directly to each managed node over SSH, copies small Python scripts called modules to a temporary directory, executes them, and removes them afterward. No Ansible-specific daemon, service, or database is ever installed or left running on the managed nodes, which reduces the attack surface and eliminates a whole category of agent-upgrade and agent-drift maintenance work that agent-based tools require.
Cricket analogy: This is like a physiotherapist who travels to the stadium with a portable kit bag, treats a player like Jasprit Bumrah, and leaves nothing behind, rather than a permanent medical device implanted in every player.
How SSH-Based Execution Works
When you run a playbook, Ansible opens an SSH connection to each target host (using OpenSSH by default via the ssh connection plugin), authenticates using an SSH key or password, transfers the relevant Python module code, and executes it with the interpreter specified by ansible_python_interpreter, capturing JSON output that Ansible parses to determine success, failure, or a 'changed' state. By default Ansible processes hosts in batches controlled by the forks setting (5 by default), meaning it can run tasks on many machines in parallel rather than strictly one at a time.
Cricket analogy: Parallel execution via forks is like a franchise running simultaneous net practice sessions for five players at once instead of coaching them one after another sequentially, saving total training time.
Control Node vs Managed Nodes
The control node is any machine with Ansible installed — typically a laptop, CI runner, or a dedicated bastion — from which you execute ansible or ansible-playbook commands; it must run Linux, macOS, or WSL, since Ansible does not support running the control node itself on native Windows. Managed nodes, by contrast, only need a supported OS, an SSH server, and Python 3 available (Ansible can even bootstrap Python via the raw module on hosts that lack it), which is why Ansible can manage everything from bare-metal servers to network switches and even Windows hosts over WinRM as a special case.
Cricket analogy: The control node is like the team's head coach in the dugout directing strategy, while the managed nodes are the players on the field who just need to be able to receive and execute instructions.
# ~/.ansible.cfg (project-level configuration)
[defaults]
inventory = ./inventory/hosts.ini
remote_user = deploy
private_key_file = ~/.ssh/id_ed25519
host_key_checking = True
forks = 10
[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s
pipelining = TrueSecurity and Authentication
Because everything travels over SSH, Ansible inherits SSH's security model: key-based authentication is strongly preferred over passwords, host key verification protects against man-in-the-middle attacks, and privilege escalation to root is handled per-task via become (typically wrapping sudo) rather than requiring you to SSH in as root directly. Secrets such as API tokens or database passwords should never be stored in plaintext in a playbook or inventory; Ansible Vault encrypts sensitive variables at rest so they can be safely committed to version control alongside the rest of the automation code.
Cricket analogy: Using become for privilege escalation is like a substitute fielder being allowed onto the field for a specific over under strict rules, rather than being handed permanent captaincy for the whole match.
Never disable host_key_checking in production without an alternative verification strategy (such as pre-populating known_hosts via configuration management). Turning it off entirely reintroduces the man-in-the-middle risk that SSH host key verification exists to prevent, even though it's a common quick fix for noisy CI logs.
- Ansible's control node connects to managed nodes over SSH; no daemon is installed on the targets.
- Modules are copied as temporary Python scripts, executed, and cleaned up after each task.
- The forks setting controls how many hosts Ansible processes in parallel (default is 5).
- The control node must run Linux, macOS, or WSL; managed nodes just need SSH and Python.
- Privilege escalation uses become/sudo per task instead of logging in as root directly.
- Ansible Vault encrypts secrets so they can be safely stored in version control.
- Disabling host key checking removes protection against man-in-the-middle attacks and should be avoided in production.
Practice what you learned
1. What happens to the Python module code Ansible copies to a managed node?
2. What does the 'forks' setting control?
3. Which operating systems can serve as an Ansible control node?
4. How does Ansible typically handle privilege escalation to root?
5. What is the purpose of Ansible Vault?
Was this page helpful?
You May Also Like
What Is Ansible?
Ansible is an open-source, agentless automation tool for configuration management, application deployment, and orchestration, driven by human-readable YAML playbooks.
Installing and Configuring Ansible
Ansible is installed via pip or a system package manager on the control node, then tuned through the layered ansible.cfg configuration file.
Inventory Files Explained
An inventory file tells Ansible which hosts exist and how they're grouped, and can be static (INI or YAML) or generated dynamically from a cloud provider or CMDB.
Ad-Hoc Commands
Ad-hoc commands run a single Ansible module against a set of hosts directly from the command line, ideal for quick one-off tasks that don't warrant a full playbook.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics