Bug 1576797 - SSH to appliance fails due to record of IP used by appliance in .ssh/known_hosts
Summary: SSH to appliance fails due to record of IP used by appliance in .ssh/known_hosts
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: ovirt-ansible-collection
Classification: oVirt
Component: manageiq
Version: 1.1.6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Ondra Machacek
QA Contact: Petr Kubica
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-10 12:12 UTC by Petr Kubica
Modified: 2021-02-12 20:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-11 12:12:27 UTC
oVirt Team: Infra
Embargoed:


Attachments (Terms of Use)

Description Petr Kubica 2018-05-10 12:12:02 UTC
Description of problem:
Role fails when a different SSH key is in known_hosts for IP which got manageiq. 

TASK [ovirt-manageiq : Fetch info about appliance] ****************************************************************************************************************************************************************
task path: /usr/share/ansible/roles/oVirt.manageiq/tasks/init_cfme.yml:15
Using module file /usr/lib/python2.7/site-packages/ansible/modules/commands/command.py
<10.37.139.159> ESTABLISH SSH CONNECTION FOR USER: root
<10.37.139.159> SSH: EXEC sshpass -d12 ssh -C -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o User=root -o ConnectTimeout=10 -o StrictHostKeyChecking=no -o ControlPath=/root/.ansible/cp/83c78051d3 10.37.139.159 '/bin/sh -c '"'"'echo ~ && sleep 0'"'"''
<10.37.139.159> (255, '', '@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r\n@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @\r\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r\nIT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!\r\nSomeone could be eavesdropping on you right now (man-in-the-middle attack)!\r\nIt is also possible that a host key has just been changed.\r\nThe fingerprint for the ECDSA key sent by the remote host is\nSHA256:ciWkr4jWkUdx+538T1w8PpFtwrMHcS+YNLFDDCf4yNY.\r\nPlease contact your system administrator.\r\nAdd correct host key in /root/.ssh/known_hosts to get rid of this message.\r\nOffending ECDSA key in /root/.ssh/known_hosts:2\r\nPassword authentication is disabled to avoid man-in-the-middle attacks.\r\nKeyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.\r\nPermission denied (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n')
fatal: [localhost]: UNREACHABLE! => {
    "changed": false, 
    "msg": "Failed to connect to the host via ssh: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r\n@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @\r\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r\nIT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!\r\nSomeone could be eavesdropping on you right now (man-in-the-middle attack)!\r\nIt is also possible that a host key has just been changed.\r\nThe fingerprint for the ECDSA key sent by the remote host is\nSHA256:ciWkr4jWkUdx+538T1w8PpFtwrMHcS+YNLFDDCf4yNY.\r\nPlease contact your system administrator.\r\nAdd correct host key in /root/.ssh/known_hosts to get rid of this message.\r\nOffending ECDSA key in /root/.ssh/known_hosts:2\r\nPassword authentication is disabled to avoid man-in-the-middle attacks.\r\nKeyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.\r\nPermission denied (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n", 
    "unreachable": true
}

Version-Release number of selected component (if applicable):
ovirt-ansible-manageiq-1.1.8-1.el7ev.noarch

How reproducible:
always - when there is old record in known_hosts

Steps to Reproduce:
1. when appliance got IP which has record in known_hosts (appliance got IP used by VM in past and from engine machine admin ran some playbooks against that VM)

Actual results:
Task fail

Expected results:
Should skip key verification in this case

Comment 1 Martin Perina 2018-05-11 12:12:27 UTC
This is standard protection even for standard class openssh client, if you have in your known_hosts key of the host which is different from the key which is sent during connection initialization, then the client automatically quits with above message.

Comment 2 Phani Gardas 2021-02-12 20:53:47 UTC
That's correct Martin, however, if a user doesn't have access to the known_hosts of the Tower environments like in enterprises, how can one bypass this?
I have gone through multiple sources, however, there is no way that I can perform the host_key_checking no through an external variable which can make the hostkeychecking not mandatory. 
Is there anyway to do this on the fly instead of having it as a variable or a host variable in the inventory as I have multiple inventories to be changed. 

Thanks, 
Phani Gardas


Note You need to log in before you can comment on or make changes to this bug.