The Short Answer
There is a file which has been changed since the last time you attempted to reach the SSH server running on that host. That file is
/Users/whateveryourusernameis/.ssh/known_hosts
Somewhere in that file is an entry, one line only, beginning with the host you tried to reach in brackets like [vpsXXX.ovh.net].
If you are certain that the server you're trying to reach is one you just changed and setup yourself, it's safe to remove that line and try again.
The Longer Answer, Phoned In
SSH is the single most basic tool on the sysadmin's belt, and how it works deserves your attention.
When you contact an ssh server, one of the first steps the server takes is to present the ssh client with its own the public host key. This key is typically appended to the client's ~/.ssh/known_hosts file, so that if this key changes in-between different ssh sessions, the client will be warned that the host is no longer the original host that it contacted before. This alerts you to the fact that the host you've reached is possibly an impostor, unless you already know without a doubt that the host has, in fact, changed.
The host key is a core part of the SSH negotiation process, which you should familiarize yourself with if you're administrating any system. This key is normally only generated once, the first time an SSH server is started up. So if you get the warning that the host key has changed, one of the following events have occurred:
- A new server (or machine image, etc.) has been deployed, and the IP address or domain name which once pointed at the former server has been changed to point at the new server (which is typical, especially in cloud environments).
- Someone has changed or deleted the public host key on the machine. I'd immediately wonder why, as there's normally no reason to— one exception may be extremely strict security procedures which rotate the key every so often. Even if so, I'd expect the new public key fingerprint to be distributed to avoid this error, in that case.
- Someone has managed to intercept your traffic sent to that IP or domain name, and has pointed it at their own server in either an ill-conceived attempt to stage a MITM SSH attack, or more likely, they've attempted to insert themselves to collect traffic on a separate port and protocol (such as HTTPS).
If you're working in a cloud environment, new machine images and instances get swapped in all the time to replace older ones. So the way to remove the warning, and continue SSH'ing to your new host, is simply to remove the offending line with the old fingerprint from your ~/.ssh/known_hosts file. As good practice goes, it's best to remove this as soon as you know the replacement has happened, and then log in once to confirm and store the new host key.
Finally, respect your fellow admins, and let them know it's happened, so that they won't feel the need to pull the fire alarm themselves.
Post-scriptum (Or, checking up on ssh-keygen -R failures)
I found a similar page to the one you did, and there was a note about new behavior which may change the identification of the public host key to some hashed value, which I hadn't heard of before— rather than [vpsXXX.ovh.net], it might look like [BF8JDF9SS@67IX] instead. If this is the case, and you're not editing too much, you can move the known_hosts file, connect via ssh, and that will create a new file with one line. That line will have the correct, hashed value of the domain or IP you connected to, and so you replace the old host key with the new one, from your newly created file. Move the edited known_hosts file back into place, and voilá— you've updated your stored public host key for that connection.
