Skipping Host Key Checking fails on changed target host key

[danielsiwiec]

Issue Type:

Bugfix Pull Request

Ansible Version:

1.7.2

Environment:

N/A

Summary:

When skipping "Host Key Checking" two flags need to be passed to ssh in order to allow connection to a host with a changed host key: StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null. Currently only the first one is passed.

Steps To Reproduce:

1. export ANSIBLE_HOST_KEY_CHECKING=False
2. ansible all -m ping -i "hostname.example.com,"
3. Change the host key (recreate the VM or change the DNS entry to point to a different IP) for the target
4. ansible all -m ping -i "hostname.example.com,"

Expected Results:

The ping should pass.

Actual Results:

debug3: load_hostkeys: loading entries for host "hostname.example.com" from file "/Users/dsiwiec/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/dsiwiec/.ssh/known_hosts:49
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "168.61.73.29" from file "/Users/dsiwiec/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for hostname.example.com has changed,
and the key for the corresponding IP address 168.61.73.29
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
d2:d3:92:8b:52:aa:4f:9b:cb:a6:f8:f1:50:04:b3:da.
Please contact your system administrator.

[mpdehaan]

In queue for investigation (not saying I agree just yet :))

[danielsiwiec]

Cool, ping me if you had problems reproducing it.

[bcoca]

I cannot reproduce the problem, once i "export ANSIBLE_HOST_KEY_CHECKING=False" I don't get any errors.

[danielsiwiec]

How did you attempt to replicate it? One easy way is to edit the know_hosts file and substitute the target host's key with a different host's key. The problem will not occur if it's a new host that doesn't have an entry in the known_hosts yet - in this case setting ANSIBLE_HOST_KEY_CHECKING to False does solve the problem.

[gildegoma]

@danielsiwiec This is a known issue (also discussed in #3694).

At the moment there is no ad-hoc Ansible option to control UserKnownHostsFile=/dev/null, but you can set this option via ssh_args in ansible.cfg (or the ANSIBLE_SSH_ARGS environment variable).

[danielsiwiec]

Thanks for pointing that out. According to documentation:

If a host is reinstalled and has a different key in ‘known_hosts’, this will result in an error message until corrected (...) You might not want this.

If you wish to disable this behavior and understand the implications, you can do so (...) by an environment variable:

$ export ANSIBLE_HOST_KEY_CHECKING=False

This functionality currently does not work, unless the UserKnownHostsFile=/dev/null property is set in SSH arguments, which is somewhat confusing. It bit me and took some time to figure out, so that's what I'm addressing with this PR.

[bcoca]

@danielsiwiec I tested this by running against the same host and regenerating keys on that host between runs. It worked in all 3 cases:

• initial host run (not in known_hosts)
• subsequent host run (while in known_hosts)
• run after regeneration of keys (known_hosts with different signature)

[gildegoma]

@bcoca In this gist @glenjamin exactly described how to reproduce a similar problem, where the solution consists in using UserKnownHostsFile=/dev/null ssh option.

[amenonsen]

I can also not reproduce this problem with devel in any of the various reported problem cases. I think this PR should be closed.

[bcoca]

closing the ticket as per comments above