# Change Request: Don't modify known\_hosts file when host\_key\_checking=False **URL:** \ **Category:** Ansible Developer\ **Created:** [June 15, 2014, 2:46pm UTC](https://forum.ansible.com/t/change-request-dont-modify-known-hosts-file-when-host-key-checking-false/15464 "2014-06-15T14:46:58Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Gilles\_Cornu](https://avatars.discourse-cdn.com/v4/letter/g/ecccb3/32.png) [@Gilles\_Cornu](https://forum.ansible.com/u/Gilles_Cornu)\ **Post date:** [June 15, 2014, 2:46pm UTC](https://forum.ansible.com/t/change-request-dont-modify-known-hosts-file-when-host-key-checking-false/15464/1 "2014-06-15T14:46:58Z")
In a “Development or Test” context (e.g. using Vagrant to spin up temporary machines), it is usually not desired to store the host key in `~/.ssh/known_hosts` file, as the related host:port is frequently reused by other machines. In this kind of simple context, we also assume that ssh-keyscan tool is not used. At the moment, it is possible to configure Ansible to not modify the known host file the following way: - paramiko connection: ANSIBLE\_PARAMIKO\_RECORD\_HOST\_KEYS=false - ssh connection: ANSIBLE\_SSH\_ARGS=‘-o UserKnownHostsFile=/dev/null’ (Note that there is no ANSIBLE\_SSH\_RECORD\_HOST, equivalent to ANSIBLE\_PARAMIKO\_RECORD\_HOST) This change request idea comes from the Vagrant context, where by default Ansible is configured so that the known host keys are not considered (via ANSIBLE\_HOST\_KEY\_CHECKING=False). But we’d also want that the known host file is not modified by Ansible. Of course, we can easily implement this behavior with the parameters listed above, but I think that having an “ssh-connection-agnostic” way to configure Ansible would be more comprehensive and could be useful in any other contexts that uses temporary “unsafe machines” that share the same host:port addresses. Therefore I see three possible approaches to resolve this issue: - Change the behavior of “ANSIBLE\_HOST\_KEY\_CHECKING=False”, so that the known\_hosts file is not modified in this case. - Introduce a new option (e.g. ANSIBLE\_RECORD\_HOST\_KEYS, set to true by default), impacting both (ssh and parmiko) connection modes (This would deprecate ANSIBLE\_PARAMIKO\_RECORD\_HOST by the way) - Introduce a new option (e.g. ANSIBLE\_USER\_KNOWN\_HOSTS\_FILE), to optionally specify the host file to use by both (ssh and parmiko) connection modes. I prefer the first approach (change behavior of “ANSIBLE\_HOST\_KEY\_CHECKING=False”) for the following reasons: - A host key that we don’t check - or even trust - should actually not be stored as _known_ host. - For openssh connection, it corresponds to usual “-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no” combination. - These _‘unnecessary’_ entries in the known hosts file will never be automatically replaced when the host key changes, leading to keep outdated information. Having a key mismatch when using ANSIBLE\_HOST\_KEY\_CHECKING=False can lead to confusing situations, like the SSH forwarding problem documented in [https://gist.github.com/glenjamin/7f1d4335e7a9760b75e5](https://gist.github.com/glenjamin/7f1d4335e7a9760b75e5). - The backward compatibility on Ansible safe default (ANSIBLE\_HOST\_KEY\_CHECKING=True) is maintained, and only the “non-standard” mode is impacted. So, I’d like to know if more people are interested in this change request and if you would you accept a patch for that? If yes, which approach do you prefer? For the first approach, I already created [d90436ea65a82aab1f746c503d8a0b68a5e315a8](https://github.com/gildegoma/ansible/commit/d90436ea65a82aab1f746c503d8a0b68a5e315a8), as a possible base for a pull request. Many thanks in advance for your reviews! Gilles Related References: - [https://github.com/ansible/ansible/issues/3694#issuecomment-22530734](https://github.com/ansible/ansible/issues/3694#issuecomment-22530734) (where the possible addition of an option to allow setting -o UserKnownHostsFile=/dev/null was discussed) - [https://github.com/mitchellh/vagrant/issues/3900](https://github.com/mitchellh/vagrant/issues/3900) (original motivation for this discussion) ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [June 16, 2014, 1:23am UTC](https://forum.ansible.com/t/change-request-dont-modify-known-hosts-file-when-host-key-checking-false/15464/2 "2014-06-16T01:23:47Z")
Not really interested in changing behavior too much just for your development use case when it’s just as easy to turn checking off. In interest in my reading comprehension of the above novel, can you give me a two sentence summary? BTW, all that you post above is settable in ansible.cfg, the environment variables are just there for legacy reasons. ---
**Author:** ![Gilles\_Cornu](https://avatars.discourse-cdn.com/v4/letter/g/ecccb3/32.png) [@Gilles\_Cornu](https://forum.ansible.com/u/Gilles_Cornu)\ **Post date:** [June 16, 2014, 3:16pm UTC](https://forum.ansible.com/t/change-request-dont-modify-known-hosts-file-when-host-key-checking-false/15464/3 "2014-06-16T15:16:13Z")
Thank you Michael for quick feedback and sorry if my verbose post was not clear. I am again word flooding below for completeness, but I hope it will be easier to navigate this time 😉 > Not really interested in changing behavior too much just for your development use case when it’s just as easy to turn checking off. There is no doubt that I can deal with the current configuration options, but I felt that Ansible could really gain to be easier to configure in that situation, hence the creation of this post. > In interest in my reading comprehension of the above novel, can you give me a two sentence summary? When [defaults].host\_key\_checking is disabled, Ansible still adds new hosts into the user known\_hosts file, which is not desirable (for the reasons explained in the original post). In this case (host key checking turned off), I propose to completely skip the user known\_hosts file (alternative solutions are also presented in the original post). > BTW, all that you post above is settable in ansible.cfg, the environment variables are just there for legacy reasons. Sure! But this note “alarmed” me a little bit by the way… Do you mean that the [environmental configuration alternative](http://docs.ansible.com/intro_configuration.html#environmental-configuration) won’t be maintained in the future? These equivalent environment variables are a great way to combine settings with an existing ansible.cfg file, so please keep them! Please let me close the second chapter of this awful novel with two examples that illustrate the “before” and “after” idea. At the moment, following settings are necessary for my use case: [defaults] host\_key\_checking = False [paramiko\_connection] record\_host\_keys = False [ssh\_connection] ssh\_args = -o UserKnownHostsFile=/dev/null By changing host\_key\_checking=False behavior (as illustrated in [d90436ea65a82aab1f746c503d8a0b68a5e315a8](https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgildegoma%2Fansible%2Fcommit%2Fd90436ea65a82aab1f746c503d8a0b68a5e315a8&sa=D&sntz=1&usg=AFQjCNEyrIwlKDZWKriFnSbIVLptt1R4Ig)), following would then be equivalent: [defaults] host\_key\_checking = False Thanks again in advance for your feedbacks! Best, Gilles ---
**Author:** ![James\_Cammarata](https://avatars.discourse-cdn.com/v4/letter/j/7c8e57/32.png) [@James\_Cammarata](https://forum.ansible.com/u/James_Cammarata)\ **Post date:** [June 16, 2014, 3:28pm UTC](https://forum.ansible.com/t/change-request-dont-modify-known-hosts-file-when-host-key-checking-false/15464/4 "2014-06-16T15:28:34Z")
The environment variable options will not go away (ever). I believe the point Michael was trying to make was that since you can create local ansible.cfg files in the working directory (which can override those set globally in /etc/ansible/ansible.cfg) it is easy enough to make this work without having to specify the env variables with every run. What you are proposing is to drastically change the meaning of the host\_key\_checking option, which we do not want to do. At the very least, we would have to create a second option (ie. save\_host\_keys = False) to implement the behavior you want, but since (as you’ve illustrated above) you can already accomplish the same thing with only 2 other lines of configuration we do not feel that this is necessary. At best, this warrants a minor tweak to the Vagrant guide ([http://docs.ansible.com/guide\_vagrant.html](http://docs.ansible.com/guide_vagrant.html)), to specifically mention setting these options would be recommended. We’d be glad to take a documentation pull request along those lines. Thanks! ---
**Author:** ![Gilles\_Cornu](https://avatars.discourse-cdn.com/v4/letter/g/ecccb3/32.png) [@Gilles\_Cornu](https://forum.ansible.com/u/Gilles_Cornu)\ **Post date:** [June 17, 2014, 6:10am UTC](https://forum.ansible.com/t/change-request-dont-modify-known-hosts-file-when-host-key-checking-false/15464/5 "2014-06-17T06:10:33Z")
> The environment variable options will not go away (ever). OK I am relieved on this point, thanks for the precision 🙂 > What you are proposing is to drastically change the meaning of the host\_key\_checking option, which we do not want to do. This was indeed the most radical variant and I understand that you don’t want to change the meaning of host\_key\_checking=False. > At the very least, we would have to create a second option (ie. save\_host\_keys = False) to implement the behavior you want, I also proposed this second variant in my initial post, which provides the following advantages: - create a “configuration contract” for possible ssh connection alternatives that might come in the future - remove this discrepancy between paramiko and ssh settings - do not force to rely on the “multipurpose” ssh\_args option > but since (as you’ve illustrated above) you can already accomplish the same thing with only 2 other lines of configuration we do not feel that this is necessary. The idea was not to spare a configuration line but to provide optimal maintenance and usage capabilities on a long term perspective. That said, I agree that this is minor stuff and your arguments to reject this proposition are totally fair. > At best, this warrants a minor tweak to the Vagrant guide ([http://docs.ansible.com/guide\_vagrant.html](http://www.google.com/url?q=http%3A%2F%2Fdocs.ansible.com%2Fguide_vagrant.html&sa=D&sntz=1&usg=AFQjCNHGcVsQAzKec7-tlMQwX4-eG_REgA)), to specifically mention setting these options would be recommended. We’d be glad to take a documentation pull request along those lines. Based on this discussion, upcoming Vagrant 1.7+ will very probably set these settings by default (see [vagrant#3900](https://github.com/mitchellh/vagrant/issues/3900)), so that Vagrant users won’t have to care about this. I also keep in mind to provide relevant updates to the Vagrant guide. James and Michael: Thank you a lot for taking time to answer to these questions. Best regards, Gilles