Bug 1505842

Summary: 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"
Product: Red Hat Satellite Reporter: Jan Hutař <jhutar>
Component: Remote ExecutionAssignee: Adam Ruzicka <aruzicka>
Status: CLOSED ERRATA QA Contact: Peter Ondrejka <pondrejk>
Severity: medium Docs Contact:
Priority: high    
Version: 6.3.0CC: achadha, ahumbe, akarimi, alsouza, aruzicka, bbuckingham, bibin.baby, cmarinea, dmule, egolov, fcami, fperalta, gtaylor, inecas, janarula, kkinge, ktordeur, mkalyat, momran, mruzicka, mtenheuv, ofalk, patalber, pdwyer, peter.vreman, rcavalca, sadas, sauchter, shisingh, smajumda, vmeghana
Target Milestone: 6.8.0Keywords: PrioBumpGSS, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tfm-rubygem-foreman_remote_execution-3.2.0 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-27 12:57:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1122832, 1316897    

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