To anyone who has used SSH long enough the above message should look familiar. Everytime a user logs into a host via SSH that hosts unique host key is stored in the users ~/.ssh/known_hosts file. If a host is not already added into this file than the first occurrence of an SSH connection will display the above message, prompting the user to either enter yes or no. By entering Yes, the servers unique host key is automatically stored into the known_hosts file, this has been implemented to prevent man in the middle attacks.

Since servers are practically dispensable these days, they are provisioned and re-provisioned at the click of a button. It is quite common for a script to perform a remote SSH login on a new system to run commands. If this script is being run by an automated process, being asked a question may prevent the script from executing.

To get around this you can disable this feature, called StrictHostKeyChecking

Disable StrictHostKeyChecking System Wide:


StrictHostKeyChecking can be disabled on both the system as a whole or on a per user basis. To disable this setting on the system simply modify the /etc/ssh/ssh_config file.

# vi /etc/ssh/ssh_config

Search For:

# StrictHostKeyChecking ask

Replace with:

#StrictHostKeyChecking no

Disabling the KnownHostsFile:

If a host key is already added to the known_hosts file but does not match the host key being presented to SSH on login, the login will still fail. This would prevent logging into a host that shares the same hostname/IP as a previously provisioned host.

To prevent this scenario from stopping your automated script you can also change the KnownHostsFile to /dev/null. Thus preventing the host key from being added to any real file.

# vi ~/.ssh/config

Append

#UserKnownHostsFile /dev/null

Thank you for reading :)



In this article, I will show you how to install ‘Ansible’ on RHEL/CentOS 7/6. Like other configuration management tools like puppet, chef and CFEngine, server software is installed on one machine and client machines are managed through the agent. Wherein Ansible, the nodes are managed by controlling machine (Ansible server) over SSH, so there won’t be any agent running on node machines.

Base Requirements    :  

  1. Controlling Machine , 
  2. Client Nodes , 
  3. Required Packages

Software Prerequisites      :  

  1. Operating System: RHEL/CentOS/Fedora and Ubuntu/Debian/Linux Mint
  2. Jinja2: A modern, fast and easy to use stand-alone template engine for Python.
  3. PyYAML: A YAML parser and emitter for the Python programming language.
  4. parmiko: A native Python SSHv2 channel library.
  5. httplib2: A comprehensive HTTP client library.
  6. sshpass: A non-interactive ssh password authentication.
Note: Use yum for installation because it will install all dependencies automatically.

My Controlling Machine and Nodes   : 

  • 192.168.87.145    server.gekvplabs.com    server
  • 192.168.87.146    node1.gekvplabs.com    node1    
  • 192.168.87.147    node2.gekvplabs.com    node2

Installation of  Ansible on On RHEL/CentOS :

  1.  Run yum update  for updating all existing packages
    1. yum update -y
  2.  Install EPEL repo 
    1. yum install epel-release
  3.  After configuring epel repository, you can install Ansible using following command
    1. sudo yum install ansible -y
  4. After installed successfully, you can verify the version by executing below command.
    1. ansible --version 


Ansible is a free configuration management tool, it supports managing the configurations of Unix-like and Microsoft windows systems. Ansible manages nodes over SSH or PowerShell and python to be installed on them.

Ansible is agent-less, that means no need of any agent installation on remote nodes, so it means there are no any background daemons or programs are executing for Ansible, when it’s not managing any nodes.

Ansible can handle 100’s of nodes from a single system over SSH connection and the entire operation can be handled and executed by one single command ‘ansible’. But, in some cases, where you required to execute multiple commands for a deployment, here we can build playbooks.