Problem:

If you get this warning/error when you run the ssh command:

$ ssh infotinks@192.168.0.100
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
3f:1b:f4:bd:c5:aa:c1:1f:ab:4e:2e:cf:53:fa:d8:59.
Please contact your system administrator.
Add correct host key in /home/infotinks/.ssh/known_hosts to get rid of this message.
Offending key in /home/infotinks/.ssh/known_hosts:3
RSA host key for 192.168.0.100 has changed and you have requested strict checking.
Host key verification failed.$

Solution:

Avoid it like this: add these options to your ssh command

 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

The total command looks like this:

$ ssh  -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no infotinks@192.168.0.100

Here is what the 2 options say in the man page:

## UserKnownHostsFile ##
Specifies one or more files to use for the user host key data-
base, separated by whitespace. The default is
~/.ssh/known_hosts, ~/.ssh/known_hosts2.

## StrictHostKeyChecking ##
If this flag is set to ``yes'', ssh(1) will never automatically
add host keys to the ~/.ssh/known_hosts file, and refuses to con-
nect to hosts whose host key has changed. This provides maximum
protection against trojan horse attacks, though it can be annoy-
ing when the /etc/ssh/ssh_known_hosts file is poorly maintained
or when connections to new hosts are frequently made. This
option forces the user to manually add all new hosts. If this
flag is set to ``no'', ssh will automatically add new host keys
to the user known hosts files. If this flag is set to ``ask'',
new host keys will be added to the user known host files only
after the user has confirmed that is what they really want to do,
and ssh will refuse to connect to hosts whose host key has
changed. The host keys of known hosts will be verified automati-
cally in all cases. The argument must be ``yes'', ``no'', or
``ask''. The default is ``ask''.

What they mean is this

UserKnownHostsFile, instead of looking at ~/.ssh/known_hosts (/home/infotinks/.ssh/known_hosts) to check for known hosts, instead check /dev/null (which is empty), so there wont be any offending keys there. Setting StrictHostKeyChecking to no will add the new key to the specified host file (by default its ~/.ssh/known_hosts or in my case /home/infotinks/.ssh/known_hosts) but since we changed it to /dev/null, the key will be written nowhere, and the system is unchanged. The end result, is you connect to the server, even if the host key doesnt match what your known_hosts key file says. The security risk is man in the middle attacks. However if your confident that the server is correct, then don’t worry.

NOTE: another solution is to remove the 3rd line from /home/infotinks/.ssh/known_hosts (why the 3rd? because look at the output “Offending key in /home/infotinks/.ssh/known_hosts:3”)