You add a host to an Ansible inventory under a friendly alias that does not resolve in DNS; it answers SSH on port 2222 as the user `deploy`. Which inventory variables make that work?

## The inventory name is a label, not an address Every inventory entry has a name. That name is what host patterns match, what `host_vars/<name>.yml` is keyed on, what appears in play output, and what `--limit` accepts. It is *not* necessarily how Ansible reaches the machine. If the name happens to resolve in DNS, Ansible will connect to it; otherwise you must say where the host actually is: ```ini [webservers] web01 ansible_host=10.2.0.7 ansible_port=2222 ansible_user=deploy ``` or in YAML: ```yaml webservers: hosts: web01: ansible_host: 10.2.0.7 ansible_port: 2222 ansible_user: deploy ``` Using stable aliases with `ansible_host` carrying the volatile address is good practice: the address can change without invalidating every `host_vars` file, playbook pattern and CI `--limit` that names the host. ## The connection variable family These are ordinary variables that the connection plugin reads, which is why they can be set anywhere variables can be set: - `ansible_host` — the address or name to connect to. - `ansible_port` — the port; SSH defaults to 22. - `ansible_user` — the remote user to log in as. - `ansible_ssh_private_key_file` — the key to authenticate with. - `ansible_connection` — the transport plugin: `ssh` (default), `local` (run on the control node without SSH), `winrm` or `psrp` for Windows, and container transports such as `community.docker.docker`. - `ansible_python_interpreter` — which Python the modules run under on the target. - `ansible_become` / `ansible_become_user` — privilege escalation defaults for the host. Because they are variables, the natural home for shared ones is a group file. A whole Windows group becomes: ```yaml # group_vars/windows.yml ansible_connection: winrm ansible_port: 5986 ansible_user: svc_ansible ``` and a single odd host keeps its exception in `host_vars/web01.yml` instead of polluting the group. ## `ansible_python_interpreter` and why it appears Ansible modules are Python programs shipped to the target and executed there, so the target needs an interpreter. Modern ansible-core defaults this to `auto`, meaning it discovers a suitable Python for the detected distribution rather than hard-coding `/usr/bin/python`. Discovery still fails on minimal images, appliances and unusual distributions, and the fix is to state it: `ansible_python_interpreter: /usr/bin/python3.11`. Setting it per group is normal for a fleet of one distro; setting it per host is normal for the one oddity. ## Inventory variables versus `~/.ssh/config` You can achieve some of this with an SSH client config — a `Host web01` block with `HostName`, `Port` and `User`. The difference is who can reproduce it. An SSH config lives on one laptop; the inventory is in the repository, reviewed, and identical on the CI runner. For anything a teammate or a pipeline must reproduce, put it in the inventory. SSH config is still the right home for purely personal preferences and for jump-host plumbing you do not want to encode per project. ## Traps worth knowing `ansible_host` is easy to confuse with `ansible_hostname`, which is a *fact* gathered from the target (its configured hostname) and has nothing to do with connecting. Setting connection variables in a role's `vars/` rather than in the inventory hides them from anyone reading the inventory to answer "where does this actually connect?". And a `host_vars` file named after the address instead of the inventory alias is silently ignored — the lookup uses the alias. ## Verifying `ansible -i inventory web01 -m ping -vvv` prints the resolved connection — the address, port and user actually used — which resolves connection arguments faster than reading the files. `ansible-inventory --host web01` dumps the variables the host resolved to.