Automation with SSH and disabling RSA key

[Whitenoise]

Automatic VPS deployments with very similar, but not identical configurations are often necessary. Creating a different image for every single system can be quite challenging though, especially if 10 or more images are needed, each one based on a different distribution. A fast and effective solution can be to create scripts that connect to the VPS right after its installation via ssh and execute the required commands.

However, if different systems are installed subsequently on the same VPS there is a problem with the ssh authentication. The usual resulting error is the following:

Code: [Select]

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
dc:38:91:41:de:47:83:52:7c:f4:2d:44:3b:41:ff:e1.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:7
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Permission denied (publickey,password).
The problem is due to the fact that the cryptographic key on the VPS is different from the one known by our client system, because the ssh demon was re-installed on the virtual server.

There are 2 methods to solve the problem.

1. Find the following line:

Code: [Select]

Offending key in /root/.ssh/known_hosts:7
The final number shows that the problem is in line 7. We can remove it with the following command:

Code: [Select]

sed -i 7d ~/.ssh/known_hosts
2. In the following way we can pass 2 specific options to ssh via command line:  StrictHostKeyChecking and UserKnownHostsFile

Code: [Select]

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@vps
What happens is basically that with UserKnownHostsFile we require the saving of the new key in /dev/null and let ssh believe that it is a new empty file, and with StrictHostKeyChecking we order ssh to accept and save the new keys automatically.

Now that this little trick has been explained, the only thing left to understand is how to avoid typing the password manually. This issue will be dealt with next time.