Verbosity is a disclosure decision · Ansible

Adding -v to a command feels like a diagnostic decision. It is also a disclosure decision, and the second one is the one that gets people into trouble, because verbose output does not stay in the terminal. It goes into scrollback, into tmux history, into the CI job log, into the ticket, into the chat channel, into the incident review document.

Everything in this part is about reading Ansible output. This lesson comes first because it establishes what you are allowed to paste.

What each level adds

Measured on ansible-core 2.21.3 with the same two-task play against one host:

Level	Output lines	What it adds
(none)	12	Task banners, per-host status words, the recap
`-v`	13	The full module result as JSON, on one line per host
`-vv`	29	Version banner, config file in effect, callback selection, `task path:` for every task
`-vvv`	73	Inventory parsing, connection trace (`ESTABLISH`, `EXEC`, `PUT`), which module file was used, result JSON pretty-printed
`-vvvv`	83	Plugin loading trace and a dump of the effective CLI and config: `connection`, `become_method`, `tags`, `inventory`, `forks`

The upstream help text is worth quoting because it sets the expectation most people work from:

Adding multiple -v will increase the verbosity, the builtin plugins currently evaluate up to -vvvvvv. A reasonable level to start is -vvv, connection debugging might require -vvvv.

-vvv as a starting point is good advice: it is the first level that shows you the connection sequence and the pretty-printed result together, which is what most diagnosis needs.

The disclosure happens at `-v`, not at `-vvvv`

This is the finding worth changing your habits over. The common belief is that -vvvv is the dangerous one. Verified on 2.21.3:

Read-only / Safea secret in a module argument, at the very first verbosity level — executed on 2.21.3— The play defines db_password as a variable and interpolates it into a command. The value used here is an obviously fake placeholder. Nothing is modified: the command is /bin/echo with changed_when false.

$ ansible-playbook -i inv.ini leak.yml -v

TASK [A task that receives the secret as a module argument] ********************
ok: [lh] => {"changed": false, "changed_when_result": false, "cmd": ["/bin/echo",
"connecting", "with", "REPLACE_ME_NOT_A_REAL_SECRET"], "delta": "0:00:00.003179",
"msg": "", "rc": 0, "stderr": "", "stdout": "connecting with
REPLACE_ME_NOT_A_REAL_SECRET", "stdout_lines": ["connecting with
REPLACE_ME_NOT_A_REAL_SECRET"]}

TASK [The same task with no_log] ***********************************************
ok: [lh] => {"censored": "the output has been hidden due to the fact that
'no_log: true' was specified for this result", "changed": false}

One -v. The secret appears twice — once in the cmd array that records the module arguments, once in stdout.

Verbose output prints module arguments

A secret that reaches a module as an argument is in the result document, and the result document prints from -v upward. That covers:

a password passed to ansible.builtin.command or shell;
a token interpolated into a uri module body or headers;
a database password in community.mysql.mysql_user;
anything a lookup resolved into a task argument;
anything decrypted from Vault and then used as a module argument — Vault protects the value at rest in the repository and does nothing about where it goes at run time.

The mitigation is no_log: true on the task, which replaces the result with a censored placeholder, as the second task above shows. Its limits are real and are covered in the secrets part: it does not censor a failure message the task itself constructed, and there is a documented ANSIBLE_DEBUG exception. Read that lesson before relying on it.

The practical rule follows directly: do not reach for -v on a play that handles secrets without knowing which tasks are no_log. Reach for -vvv on a reproduction you have constructed with fake values.

`-vvvv` and the myth of automatic SSH debugging

Folklore says -vvvv gives you ssh -vvv. On ansible-core 2.21.3 it does not.

Read-only / Safe-vvvv against an unreachable host, showing the ssh command line — executed on 2.21.3— 192.0.2.11 is a documentation-range address, unreachable by design. The SSH: EXEC line shows the exact ssh invocation Ansible built. There is no -vvv in it.

$ ansible-playbook -i inv.ini one.yml -vvvv

<192.0.2.11> ESTABLISH SSH CONNECTION FOR USER: None
<192.0.2.11> SSH: EXEC ssh -C -o ControlMaster=auto -o ControlPersist=60s
-o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,
gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10
-o 'ControlPath="/home/ops/.ansible/cp/a87e32107b"' -o NumberOfPasswordPrompts=1
192.0.2.11 '/bin/sh -c '"'"'echo ~'"'"''
<192.0.2.11> (255, b'', b'ssh: connect to host 192.0.2.11 port 22: Connection
timed out')

SSH CLI verbosity is a separate, explicit option on the ssh connection plugin, and it defaults to 0:

Read-only / Safethe ssh connection plugin verbosity option — read from ansible-doc on 2.21.3— ansible-doc prints the plugin documentation shipped with the installed ansible-core. Nothing is executed against a host.

$ ansible-doc -t connection ssh | grep -A 10 '^   verbosity'

   verbosity  Requested verbosity level for the SSH CLI.
      set_via:
        env:
        - name: ANSIBLE_SSH_VERBOSITY
        ini:
        - key: verbosity
          section: ssh_connection
        vars:
        - name: ansible_ssh_verbosity
      default: 0
      type: int

Read-only / Safeasking for ssh debugging explicitly — executed on 2.21.3— ANSIBLE_SSH_VERBOSITY=3 appends -vvv to the ssh command line, and the OpenSSH debug output comes back in the error message. Note that this works at -vvv; it is independent of the Ansible verbosity level.

$ ANSIBLE_SSH_VERBOSITY=3 ansible-playbook -i inv.ini one.yml -vvv

<192.0.2.11> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s ...
<192.0.2.11> (255, b'', b'debug1: OpenSSH_10.2p1, OpenSSL 3.5.5
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 192.0.2.11 is address
debug1: auto-mux: Trying existing master at "/home/ops/.ansible/cp/a87e32107b"
debug1: Control socket does not exist
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.0.2.11 [192.0.2.11] port 22.
debug1: connect to address 192.0.2.11 port 22: Connection timed out')

Set it per host or per group, not globally

ansible_ssh_verbosity is settable as an inventory variable, which is much better than an environment variable for a fleet: put it on the one group that is failing, and the rest of the run stays readable.

[bastion_backed]
app-047 ansible_ssh_verbosity=3

This matters at scale. SSH debug output is roughly forty lines per connection attempt. Turning it on globally for a 300-host run produces a log nobody will read, and buries the three hosts you cared about.

`--diff` is a separate disclosure decision

--diff prints the content a file module would write. On a rendered template, that is the rendered file — including every credential the template interpolated.

It is the best configuration review surface Ansible has, and it is a disclosure of file contents by definition. The two facts are the same fact. Use it deliberately, and never in a pipeline whose output is readable by more people than the file is.

Before you paste

The checklist that belongs next to your keyboard:

Check	Why
Any `cmd` or `module_args` in the output?	Module arguments are printed from `-v`
Any `stdout` from a command that echoed a value?	The command output is in the result too
Any `SSH: EXEC` line?	Usernames, bastion addresses, key paths, ports
Any `--diff` hunk?	File contents, verbatim
Any `ansible-config dump` output?	Vault password file paths, log paths, custom plugin paths
Where is this going?	A ticket, a chat channel and a CI log all have different audiences and different retention

The CI job that publishes -vvvv

The recurring incident: someone adds -vvvv to a pipeline step while debugging a flaky deployment, it works, and the flag stays. Six weeks later that pipeline runs a play that handles a vault password, and every build log in the project history now contains it.

Three properties make this worse than a terminal leak. The log is retained by default, often for months. It is readable by everyone with repository access, which is a much larger set than the people trusted with the credential. And deleting the log does not undo the disclosure, because you cannot know who read it — so the response is rotation, not deletion.

The control is not “be careful”. It is that verbosity flags in pipeline definitions are reviewed like any other production configuration, and secret scanning runs against build output rather than only against the repository.

Under the hood

Why does the module result print at -v when the connection detail needs -vvv?

The verbosity integer is passed to the display object and every call site chooses its own threshold. The default callback plugin prints the serialised task result whenever verbosity is at least 1; the connection plugins log their ESTABLISH, EXEC and PUT messages at level 3; the plugin loader traces at level 4.

There is no central policy that ranks these by sensitivity. The levels express how much implementation detail you asked for, and the fact that the most sensitive content is at the lowest level is an accident of which component chose which number. The result document is the primary thing a callback exists to display, so it naturally sat at level 1.

This is worth understanding rather than memorising, because it explains why the mitigation lives on the task (no_log) rather than on the verbosity level. There is no -v level that shows you connection detail while hiding module arguments, and there cannot be, because they are emitted by different components with independent thresholds.

What happens if I only ever run with the log_path set and never use -v interactively?

You get the same disclosure with a longer retention, which is usually worse.

log_path writes what would have printed, at whatever verbosity was in effect, into a file that persists. If the play does not use no_log and the run used -v, the secret is now on disk on the controller, in a file whose permissions default to whatever the controller user umask produced, backed up along with everything else on that machine.

Two things make a log destination safe rather than convenient: the file must be mode 0600 and owned by the automation account, and the play must use no_log on every task that touches a credential. The second one is doing most of the work — file permissions protect against other users on the controller, not against the backup, the log shipper, or the person who tars the directory to attach it to a ticket.

Knowledge check

Why this matters

Debugging is the activity during which people are least careful about disclosure, because attention is entirely on the problem and the output is a means to an end.

That is exactly when the output travels furthest. A stuck deployment produces a paste into a chat channel, an attachment on a ticket, a snippet in an incident review, and a CI log that outlives all three. The information you were reading for thirty seconds is retained for years by systems chosen for searchability.

The habit that prevents it is small: know what your verbosity level prints before you choose it, run reproductions with fake values, put no_log on the tasks that handle credentials before you need it, and read the output once before pasting it. None of that slows down diagnosis. What slows down diagnosis is a credential rotation across a fleet at the end of a night that was already going badly.