Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1505842 - Remote 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"
Summary: Remote Execution engine: Error initializing command: Net::SSH::HostKeyMismatc...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Remote Execution
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: 6.8.0
Assignee: Adam Ruzicka
QA Contact: Peter Ondrejka
URL:
Whiteboard:
Depends On:
Blocks: 1122832 1316897
TreeView+ depends on / blocked
 
Reported: 2017-10-24 11:30 UTC by Jan Hutař
Modified: 2024-10-01 16:06 UTC (History)
31 users (show)

Fixed In Version: tfm-rubygem-foreman_remote_execution-3.2.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-27 12:57:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 21449 0 Normal Closed Remote Execution engine: Error initializing command: Net::SSH::HostKeyMismatch - fingerprint 20:a9:b7:45:1a:b7:d6:42:1e:... 2021-02-18 17:47:06 UTC
Red Hat Knowledge Base (Solution) 3708891 0 None None None 2018-11-21 11:57:55 UTC
Red Hat Product Errata RHSA-2020:4366 0 None None None 2020-10-27 12:57:47 UTC

Internal Links: 2058894

Description Jan Hutař 2017-10-24 11:30:07 UTC 
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
Comment 1 Jan Hutař 2017-10-24 11:30:51 UTC 
Forgot to mention:

tfm-rubygem-net-ssh-4.0.1-2.el7sat.noarch
Comment 3 Adam Ruzicka 2017-10-25 08:42:17 UTC 
Created redmine issue http://projects.theforeman.org/issues/21449 from this bug
Comment 11 Peter Vreman 2019-03-19 16:46:50 UTC 
On Sat6.5.0HTB problem is still there. Even doing a build=no and build=yes to make the provisioning in a clean for rebuilding it does not clean the ssh entry
Comment 12 Peter Vreman 2019-03-19 16:57:26 UTC 
My use case for re-kickstarting uses the following 2 commands to force a clean hosts entry for biulding (including a new kickstart token)

hammer host update --name testserver.test.com --managed yes --build no
hammer host update --name testserver.test.com --managed yes --build yes

After the second command i expect that also the entries in the ssh known_hosts files for testserver.test.com are cleaned on the sat6 serfver and all capsules.
Current behaviour is inconsistnet with e.g. the facts that are actually cleaned when switching to 'Build'
Comment 14 Oliver Falk 2019-03-20 12:25:05 UTC 
As pointed out in the upstream issue:

    [ Remote Execution engine: Error initializing command: Net::SSH::HostKeyMismatch ... ]
    https://projects.theforeman.org/issues/21449

My suggestion would be to set ~foreman-proxy/.ssh/config to completely ignore ssh keys by default:

    Host *
      UserKnownHostsFile=/dev/null
      StrictHostKeyChecking=no

For RHSAT and for the Capsules.
Comment 21 Bryan Kearney 2019-11-25 09:04:23 UTC 
Upstream bug assigned to aruzicka
Comment 22 Bryan Kearney 2019-11-25 09:04:26 UTC 
Upstream bug assigned to aruzicka
Comment 23 Bryan Kearney 2019-12-03 11:04:30 UTC 
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/21449 has been resolved.
Comment 24 Adam Ruzicka 2019-12-03 11:08:20 UTC 
Still ASSIGNED, this consists of two PRs, only one was merged.
Comment 25 Bryan Kearney 2019-12-03 13:04:36 UTC 
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/21449 has been resolved.
Comment 32 Peter Ondrejka 2020-07-22 11:22:26 UTC 
Verified on satellite 6.8 snap 9, executing a remote command on reprovisioned client no longer fails with key mismatch
Comment 38 errata-xmlrpc 2020-10-27 12:57:21 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.8 release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4366
Note You need to log in before you can comment on or make changes to this bug.