Deleting host in Foreman UI does not remove host key from known_hosts

Problem:

Link to older post: 37449.

When I delete a host from Foreman UI (3.17 standalone - no Katello) the corresponding host key is not purged from the /usr/share/foreman-proxy/.ssh/known_hosts file. This affects Foreman REX feature because of host key mismatch when a VM is recreated.

For comparison, I have a legacy Foreman (3.13 standalone - no Katello) instance where the /usr/share/foreman-proxy/.ssh/known_hosts file is purged whenever I delete a host from the Foreman UI:

[root@foreman-prod (Production) ~]$ grep -i delete /var/log/foreman-proxy/proxy.log
2026-05-05T14:13:33 6a71e0d6 [I] Started DELETE /ssh/known_hosts/foo-123456.operations.internal 
2026-05-05T14:13:33 6a71e0d6 [I] Finished DELETE /ssh/known_hosts/foo-123456.operations.internal (2.81 ms)

I’ve compared UI settings on both instances but can’t see any related parameter (no ansible plugin instlalled on either instance). On both instances, hosts are not “managed”.

Expected outcome
The /usr/share/foreman-proxy/.ssh/known_hosts file is purged when a host is deleted from Foreman UI.

Foreman and Proxy versions
Foreman 3.17, standalone - no Katello.

Foreman and Proxy plugin versions:
rubygem-foreman_maintain-1.13.6-1.el9.noarch
rubygem-foreman_remote_execution-16.3.1-1.fm3_17.el9.noarch
rubygem-foreman_puppet-9.1.0-1.fm3_17.el9.noarch

This is indeed how it used to work at some point in the past, but that has changed. I’ll point you back to the older thread, this comment describes how it is expected to work.

That shouldn’t be the case, assuming foreman knows the vm got recreated.

Ok, I can confirm Foreman REX works when a VM is recreated IF the host is deleted and recreated in Foreman afterwards (before running a REX job).

Probably because, as you mentioned in your comment, Foreman then considers that this is a new REX job for that (new) host and then cleans up the entry in the foreman-proxy’s known_hostsfile (but no purge triggered by the host delete action as on Foreman 3.13) prior to opening the ssh connection.

Thank you for the help!

1 Like