REDHAT-BUG-2571719: Medium severity vulnerability
When trust-on-first-use is enabled (hostkeyautoadd on the libssh plugin, or AutoAddPolicy in pylibssh), a host that is already in knownhosts but now presents a different key is accepted without warning: the controller authenticates to it, runs the play there, and appends the new key to knownhosts. Defaults are not affected - with hostkeychecking on and hostkeyautoadd unset, non-interactive runs fail closed. Root cause: pylibssh Session.verifyknownhost() passes SSHKNOWNHOSTSCHANGED and SSHKNOWNHOSTSOTHER to the same missinghostkey() policy hook used for unknown hosts. The hook name and the bundled AutoAddPolicy/RejectPolicy classes follow paramiko, where that hook is consulted only for absent hosts and a mismatched key raises BadHostKeyException. ansible.netcommon's MyAddPolicy, documented as "Based on AutoAddPolicy in paramiko", therefore adds changed keys as well. libssh's own tutorial stops the connection on both states. Verified on ansible-pylibssh 1.4.0 / libssh 0.12.0; ansible-core 2.21.5, ansible.netcommon 8.7.1 (ansible 14.5.0); ansible.netcommon.libssh and networkcli with sshtype=libssh. Reporter: Satriyo Utomo (aleens-labs).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Keep host_key_checking enabled and leave host_key_auto_add unset so non-interactive runs fail closed when a known host presents a changed key; do not enable trust-on-first-use via host_key_auto_add on or pylibssh AutoAddPolicy.
ansible.netcommon libssh plugin / pylibssh host_key_checking and host_key_auto_add = host_key_checking=on; host_key_auto_add=unset
Event History
Frequently Asked Questions
Which configurations are exposed to accepting a changed SSH host key?
The issue affects trust-on-first-use configurations: host_key_auto_add on the libssh plugin or AutoAddPolicy in pylibssh. It was verified with ansible.netcommon.libssh and network_cli when ssh_type=libssh is used.
Are standard non-interactive configurations affected?
No. With host_key_checking enabled and host_key_auto_add unset, non-interactive runs fail closed rather than accepting an unknown or changed key.
What access would an attacker need to exploit this?
An attacker would need to make a host already recorded in known_hosts present a different SSH host key to the controller. Under the affected auto-add policies, the controller then authenticates, runs the play, and appends the replacement key to known_hosts.
What mitigation is available if an update cannot be applied immediately?
Do not enable host_key_auto_add or AutoAddPolicy, and keep host_key_checking enabled. This causes non-interactive runs to fail instead of accepting changed host keys.
Which component behavior causes the issue?
pylibssh Session.verify_knownhost() sends changed-key and other-key states to the missing_host_key() policy hook used for unknown hosts. Auto-add policies consequently treat changed keys as hosts that can be added.