Bug #21449
closedRemote Execution engine: Error initializing command: Net::SSH::HostKeyMismatch - fingerprint 20:a9:b7:45:1a:b7:d6:42:1e:03:d1:1f:06:20:4c:e2 does not match for "172.17.0.101"
Description
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1505842
Description of problem:
Remote Execution engine remembers ssh fingerprints of clients and when client is reinstalled, it fails with:
Error initializing command: Net::SSH::HostKeyMismatch - fingerprint 20:a9:b7:45:1a:b7:d6:42:1e:03:d1:1f:06:20:4c:e2 does not match for "172.17.0.101"
Version-Release number of selected component (if applicable):
satellite-6.3.0-21.0.beta.el7sat.noarch
How reproducible:
always
Steps to Reproduce:
1. Execute remote command on client
2. Reinstall that client (or somehow force it to change sshd fingerprint)
and register it back with same name and IP
3. Attempt to execute another remote command
Actual results:
Error message mentioned above
Expected results:
I'm not saying this is a wrong behavior. It is up to somebody else, but if it is going to stay this way, that change needs to be documented.
Additional info:
Info from aruzicka:
<aruzicka> jhutar: so, apparently it is a new thing in net-ssh 4.0+ (sat 6.2 had net-ssh 2.4.something). there's an issue about this in its upstream repo, but i don't think they'll fix it anytime soon
<aruzicka> jhutar: so if you could please open a BZ and we'll probably make some fix on our side
Updated by Adam Ruzicka about 7 years ago
- Category set to Foreman
- Target version set to 113
Updated by Alex Fisher almost 7 years ago
- Is duplicate of Bug #18645: Remote command fails due to HostKeyMismatch added
Updated by metal cated almost 7 years ago
Is there a fix for this? I just started having this problem on one of my Foreman servers. Please let me know, thanks!
Foreman: 1.15.6-1
Katello: 3.4.5-1
tfm-rubygem-foreman_remote_execution-1.3.7-1.fm1_15.el7.noarch
tfm-rubygem-foreman_remote_execution_core-1.0.6-1.fm1_15.el7.noarch
tfm-rubygem-hammer_cli_foreman_remote_execution-0.0.5-2.fm1_12.el7.noarch
Updated by Adam Ruzicka almost 7 years ago
Workaround is to purge /usr/share/foreman-proxy/.ssh/known_hosts (or just remove the one conflicting record) on Foreman (or Smart Proxies). Permanent workaround is to make /usr/share/foreman-proxy/.ssh/known_hosts a symlink to /dev/null so the issue won't happen again when the host keys change again. But please bear in mind this is supposed to be a security feature which may indicate something went wrong.
Updated by metal cated almost 7 years ago
OK that makes sense. Thanks for pointing me to the location of where the known_hosts file is for the foreman-proxy user.
The hosts which are offending at the moment are test provisioning servers. So what I am going to do and others who are in my situation should do and ONLY for machines that you plan to provision over and over for testing is to use a /usr/share/foreman-proxy/.ssh/config file and define ONLY those servers have a /dev/null UserKnownHostsFile: i.e. ->
Host hostname.domain.com
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no
I think clearing the known_hosts file will solve a one time conflict but symlinking known_hosts to /dev/null would be less secure that using the above if the situation calls for it. My 2 cents ;)
Thanks!
Updated by The Foreman Bot about 5 years ago
- Status changed from New to Ready For Testing
- Assignee set to Adam Ruzicka
- Pull request https://github.com/theforeman/smart_proxy_remote_execution_ssh/pull/45 added
Updated by The Foreman Bot about 5 years ago
- Pull request https://github.com/theforeman/foreman_remote_execution/pull/451 added
Updated by Adam Ruzicka about 5 years ago
- Status changed from Ready For Testing to Closed
Applied in changeset foreman_proxy_plugin|ee9d66837bf9d0b9ffc961c88eeef0f9ec3d49e5.
Updated by Adam Ruzicka almost 5 years ago
- Status changed from Closed to Assigned
- Triaged set to No
There are still changes that need to be done
Updated by The Foreman Bot almost 5 years ago
- Status changed from Assigned to Ready For Testing
Updated by Adam Ruzicka over 4 years ago
- Status changed from Ready For Testing to Closed
Applied in changeset foreman_plugin|734acd451fac04ab0ebb9c348271bc66c69df3b8.
Updated by Adam Ruzicka over 4 years ago
- Fixed in Releases smart_proxy_remote_execution_ssh-0.3.0 added
Updated by Adam Ruzicka over 4 years ago
- Fixed in Releases foreman_remote_execution 3.2.0 added
- Fixed in Releases deleted (
)
Updated by Adam Ruzicka over 3 years ago
- Related to Bug #32606: Reimplement known host key removal added