The server key lands in known_hosts on the first connection. If the server later offers a different key, ssh stops.
A server with a new key
The training server was reinstalled. Connect to it, then print the fingerprint of the key stored on the server itself, in /opt/ssh-lab/host_key.pub.
First, predict
known_hosts holds the server's previous key. What will ssh training id -un do?
Now start the exercise, run the command and compare your prediction with the output.
This time the key changed legitimately: the server was reinstalled, and the fingerprint — a short form of the key — matches the one stored on the server itself. A substitution looks exactly the same, though: someone sits between you and the server. So you compare the fingerprint with a source you trust: the server console, a message from its administrator. ssh-keyscan fetches the key over the same network and cannot tell a substitution apart.
Once the fingerprint matches, remove the old entry and connect again. With no entry, ssh asks whether to trust the key: instead of yes you can paste the fingerprint you checked, and ssh compares it for you.