The security concept is that you do a manual / out-of-band verification of the server key fingerprint once for every new server that you connect to, to ensure that you connect to the actual server you want to access and that you're not connecting to the wrong server or a man-in-the-middle or other attacker.
When the finger prints match you add the server key to your known_hosts and you will only be be prompted again when suddenly that trusted key is no longer offered by the server. In that case either the server key has changed, or there is some foul play but either way you need to investigate.
In practice and especially in a large environment that manual finger print validation often isn't practical. Running the ssh-keyscan can be expedient to populate the known_hosts (once) but assumes that there is currently no MITM or other foul play. The current status will be the accepted base-line and you will only be able to detect future server key changes.
That removes some of the security but can be an acceptable risk.
To revert from any server key that was accepted accidentally trusted, it needs to be removed from the known_hosts file.
Your options are:
- delete all trusted server keys by completely deleting
˜/.ssh/known_hosts
- manually edit
˜/.ssh/known_hosts and remove the lines with the specific entry for the server(s).
If you accessed the remote server by different means, for example with both a hostname and the IP-address there can be server keys for each in the known_hosts
- sometimes the hostnames in
˜/.ssh/known_hosts are hashed (when the HashKnownHosts directive for ssh is enabled) you can't manually edit ˜/.ssh/known_hosts and you should use ssh-keygen -R HOSTNAME to remove the stored key for that HOSTNAME. Again there can be different entries for hostname, hostname.example.com and the ip-address of that host.
