Linux / Unix: Disable OpenSSH Host Key Checking

I've a remote Unix server running with OpenSSH remote login service. The openssh is configured for passwordless login using ssh keys. Our ISP allows to boot all Linux servers into the rescue mode. It allow us to bring a server online remotely in order to troubleshoot system problems that would normally only be resolved by an OS Reload (such as accidentally deleting files or wrong firewall configurations blocking ssh access). When server boots into a remote rescue mode I can connect using SSH. They SSH keys will not be the same in the rescue mode so I get key mismatch messages as SSH keys are re-generated on each boot:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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
e1:9b:5c:16:a6:cd:11:10:3a:cd:1b:a2:16:cd:e5:1c.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:1
RSA host key for www.cyberciti.biz has changed and you have requested strict checking.
Host key verification failed.

How do I ignore OpenSSH hos key checking from my Apple OS X laptop while login using the ssh?

The UserKnownHostsFile option defines a file to use for the user host key database instead of the default ~/.ssh/known_hosts. You can set this to /dev/null. The StrictHostKeyChecking must be set to no", so that 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 automatically in all cases. The argument must be "yes", "no" or "ask". The default is set to "ask". The syntax is as follows:

 
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@server1.example.com
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@www.cyberciti.biz
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@nixcraft.com
ssh -o UserKnownHostsFile=/dev/null,StrictHostKeyChecking=no user@nixcraft.com
 

WARNING! These examples demonstrates a pretty serious security issues. I strongly suggests that you use the ssh-keygen command to get rid of this problem in secure manner.

You can define the bash shell alias as follows:

 
alias newssh='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
 

You can use the command as follows:

 
newssh user@server1.example.com
newssh vivek@www.cyberciti.biz
 

A Note About rsync Command

The syntax is as follows:

 
rsync -e 'ssh -o UserKnownHostsFile=/dev/null,StrictHostKeyChecking=no' -avr filename vivek@www.cyberciti.biz:/path/to/dest
 
rsync -e 'ssh -o UserKnownHostsFile=/dev/null,StrictHostKeyChecking=no' -avr /path/to/src vivek@www.cyberciti.biz:/path/to/dest
 

As I said earlier this could lead into a security issue, so pass the -R option to ssh-keygen command to removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts. If your remote hostname is www.cyberciti.biz, enter:
$ host www.cyberciti.biz
$ ssh-keygen -R www.cyberciti.biz
$ ssh-keygen -R 1.2.3.4
Note: You need to replace the www.cyberciti.biz and 1.2.3.4 with actual host name and IP address.