Ansible: verify host identity before releasing the job
Accepting an automation run requires identifying the destination it is authorized to administer. We propose a workflow that connects that authorization to the environment actually executing each job.
Auf Portugiesisch lesenBy Pentesty
Understand the reported condition before classifying the environment
The Red Hat advisory describes changed-key acceptance in ansible-pylibssh and ansible.netcommon’s libssh plugin with auto-add enabled. Exploitation requires interception and an existing host record; default non-interactive runs reject the connection.
CVE-2026-126641 motivates this assessment. Start the business decision with a specific job able to reach a device. Select a representative automation task, its destination group and the team responsible for network changes. The workflow below is a proposed authorized assessment, not a finding that your environment suffered interception or that every deployment is exposed.
Identify what executed that connection
Collect the job identifier, execution environment image, installed collections, selected transport and configuration sources. Gather this information in the context the controller actually uses. A file reviewed on an administrator’s computer may be only one input to the process. Identify who can change each input between its review and the execution it is intended to govern.
The original disclosure distinguishes ANSIBLE_LIBSSH_HOST_KEY_AUTO_ADD from network_cli’s ANSIBLE_HOST_KEY_AUTO_ADD: the latter is not forwarded to the libssh transport.
Build a small table for each asset group, showing the observed transport and the configuration reference that selected it. Keep a group pending when its connection path cannot be confirmed. Identify approved credentials through vault references, without copying their values into the table or a report shared across the organization.
Establish the provenance of the approved identity
For each selected destination, ask its asset owner for an approved identity reference through an independently established channel. Connect that confirmation to the device’s name, address and purpose in the inventory. The team should be able to explain why it accepts that reference and who has authority to replace it, including during a legitimate server replacement.
Treat a planned replacement as an asset change: record the previous identity, new reference, maintenance window and approval. If an unexpected mismatch appears, preserve the observed record and refer it for investigation before authorizing another run. Acceptance should not depend on someone recognizing a warning visually while trying to complete an urgent task.
Rehearse rejection without production secrets
In an authorized lab, present a different identity at the same address. The mismatch should block the job from proceeding.
Define that expected result before the exercise and use synthetic accounts and data. Record where execution stopped and which files or logs it produced. Check that the evidence accepted by the next job still corresponds to the approved reference. Do not turn a production window into a laboratory or reuse real passwords to demonstrate the weakness.
Include an operational handover in the exercise. A second reviewer receives only the ticket, permitted references and results, then explains which destination was authorized and why the task stopped. A conclusion that depends on private messages from the first operator still needs documentation before it can support an operational decision.
Connect the next run to what received approval
After the review, retain an identifier for the execution image and examined configurations. Agree which changes require another rehearsal: transport selection, environment replacement, inventory changes or a different identity reference. Give the automation owner these conditions together with the authorization to resume the specific jobs covered by the assessment and any outstanding issues.
Our analysis of OpenSSH on Alpine covers a separate event concerning accounts and the authentication service. The criterion proposed here follows the destination accepted by automation. Connect both activities in the inventory while retaining the scope and evidence supporting each assessment.
Frequently asked questions
Which job should enter the workflow first?
Choose an automation task with an accountable owner, known destinations and a reproducible environment. Use that sample to clarify dependencies before expanding the scope.
Does a legitimate server replacement resolve the mismatch?
The new identity needs traceable approval. Connect the replacement to its asset, maintenance window and the person authorized to accept the change.
Should the report include the credentials used?
Retain identifiers and access references. Keep credential values in approved systems and limit who receives detailed technical records from the assessment.
When should the assessment be repeated?
Define triggers in the acceptance record, including changes to the execution environment and connection path. Identify who tracks those changes and outstanding issues.
Sources and references
Original Pentesty analysis, published November 13, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.