What the warning says
A server proves its identity with a host key. When the key differs from the one your client saved earlier, OpenSSH shows REMOTE HOST IDENTIFICATION HAS CHANGED and refuses the connection. The client cannot tell a harmless change from an attack, so treat the warning as unresolved until you have checked it.
Common causes
The usual causes are a reinstalled server, a VM restored or cloned from an image, an address now assigned to a different machine, and a load balancer that sends you to different nodes. An attacker intercepting the connection produces the same warning. If you did not expect a change, stop and do not enter a password.
Compare the fingerprints
Read the real fingerprint on the server through a channel that does not depend on this SSH connection, such as the provider console or a hypervisor console. The ssh-keyscan command only shows what the network presents to you, so it proves nothing by itself. It is useful only for comparing with the value from the console.
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
ssh-keyscan -t ed25519 server.example | ssh-keygen -lf -Replace the old entry
Only after the fingerprints match, remove the old entry and connect again. A non-standard port has its own entry written with square brackets. ssh-keygen keeps the previous file as known_hosts.old. Do not turn off StrictHostKeyChecking and do not delete the whole known_hosts file, because that removes the protection for all your servers.
ssh-keygen -R server.example
ssh-keygen -R '[server.example]:2222'
ssh user@server.exampleAvoid the warning after a reinstall
If you plan to rebuild a server and want to keep its identity, back up the host keys in /etc/ssh securely and restore them with the same owner and permissions. Do the opposite with clones: every machine made from one image needs its own host keys, otherwise several servers share one identity.
Host keys in CH-J Server Manager
The app stores SHA-256 fingerprints of host keys in its encrypted vault, separately from the OpenSSH known_hosts file. On a change it blocks the connection and shows the known and the new fingerprint. The entry is replaced only if you confirm, and cancelling changes nothing. In Alpha 0.1.1 the check also covers each jump host, and a running transfer stops when the key changes. The app cannot verify the new fingerprint for you, so the check through another channel stays your job.