Quick answer
The server host key proves which machine your SSH client is connecting to. It is different from the public key that identifies you to the server. Verify a new or changed server fingerprint through a trusted independent source before accepting it.
Before you start
Use the hostname and port provided for your hosting account. Obtain the expected fingerprint from a trusted support response or an already authenticated server-management channel. Do not treat the fingerprint shown by the unverified connection as independent confirmation of itself.
What to do
- Start a normal terminal connection to the specified host and port and note the host-key type and fingerprint in the prompt.
- Compare it with the independently obtained value for that exact server. Ask support to clarify if a DNS or server migration has changed the destination.
- Accept the key only after the values match, then test a harmless read as the correct account user.
- If an existing host key changes unexpectedly, stop. Preserve the warning and investigate rather than automatically deleting known_hosts or disabling strict checking.
Check the result
Reconnect and confirm that SSH uses the trusted identity without a mismatch warning. Record the verified server name and fingerprint with the connection setup notes.
If something does not work
A legitimate server replacement can change a fingerprint, but it still needs verification. Ask the AI assistant to explain the warning; do not let it bypass the check just to complete deployment.
Related help
- Fix Permission denied (publickey) when connecting an AI coding tool
- Troubleshoot cPanel, SSH and SFTP login problems
- Troubleshoot SSH timeouts and connection refusals
Official references
Reviewed October 31, 2026. Interfaces, vendor availability, and account features can change. Check your current account before making changes.
