Project

General

Profile

Actions

Bug #21449

closed

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"

Added by Adam Ruzicka about 7 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Foreman
Target version:
-

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


Related issues 2 (1 open1 closed)

Related to Foreman Remote Execution - Bug #32606: Reimplement known host key removalClosedAdam RuzickaActions
Is duplicate of Foreman Remote Execution - Bug #18645: Remote command fails due to HostKeyMismatchNew02/23/2017Actions
Actions #1

Updated by Adam Ruzicka about 7 years ago

  • Category set to Foreman
  • Target version set to 113
Actions #2

Updated by Alex Fisher almost 7 years ago

  • Is duplicate of Bug #18645: Remote command fails due to HostKeyMismatch added
Actions #3

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

Actions #4

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.

Actions #5

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!

Actions #6

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
Actions #7

Updated by The Foreman Bot about 5 years ago

  • Pull request https://github.com/theforeman/foreman_remote_execution/pull/451 added
Actions #8

Updated by Adam Ruzicka about 5 years ago

  • Status changed from Ready For Testing to Closed
Actions #9

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

Actions #10

Updated by The Foreman Bot almost 5 years ago

  • Status changed from Assigned to Ready For Testing
Actions #11

Updated by The Foreman Bot over 4 years ago

  • Fixed in Releases added
Actions #12

Updated by Adam Ruzicka over 4 years ago

  • Status changed from Ready For Testing to Closed
Actions #13

Updated by Adam Ruzicka over 4 years ago

  • Fixed in Releases smart_proxy_remote_execution_ssh-0.3.0 added
Actions #14

Updated by Adam Ruzicka over 4 years ago

  • Fixed in Releases foreman_remote_execution 3.2.0 added
  • Fixed in Releases deleted ()
Actions #15

Updated by Adam Ruzicka over 3 years ago

  • Related to Bug #32606: Reimplement known host key removal added
Actions

Also available in: Atom PDF