Verify the new host key
Verify a changed SSH host-key fingerprint and key type through a separate trusted route before accepting the new identity.
A changed host key can follow a planned rebuild or rotation, but may also mean a wrong DNS target or interception. Stop before entering credentials or forwarding an agent; record the hostname, port, key type and fingerprint without sharing private material.
OpenSSH warns on changed host identity specifically to protect against server spoofing. Disabling strict host-key checking or deleting every known-host entry to make the warning disappear defeats that protection.
Check the planned change independently
Confirm through a previously trusted Novasean account or support route whether the VPS was rebuilt, moved or had host keys rotated at that time. Match the intended service identifier and hostname, not merely a familiar IP address. If the event was unplanned or support cannot confirm it, treat the connection as suspicious and wait for operator investigation.
On a managed VPS, the Novasean operator can obtain the host public-key fingerprint from the actual guest or console through its trusted access. Ask for that value through an independently authenticated channel. A fingerprint fetched from the same untrusted SSH connection is not independent verification.
Compare the full fingerprint and key type
Compare the trusted fingerprint with the one presented by your SSH client, including algorithm and full value. OpenSSH documents displaying host-key fingerprints and checking known hosts. A match to an operator-supplied value for the exact VM and host is grounds to accept the new key under your access policy. A mismatch, different key type or unexplained second change is a stop condition, not an invitation to retry with security checks disabled.
Only after verification should you update the specific saved entry for that hostname and port using your client’s normal workflow, then reconnect and confirm that the warning is gone. Keep the change record for the next operator or agency handover.
Illustrative decision: if the trusted console fingerprint differs from the one SSH presents for the same host and key type, stop. Do not remove the old known-host entry to make the prompt disappear.
Compare like for like: a different host-key algorithm can be offered for the same host, so obtain the trusted fingerprint for the exact key type shown.
Escalate without weakening SSH
If you cannot obtain an independent fingerprint, leave the old trust record in place and contact support with the warning and planned-change context. If you already accepted an unverified key or entered a password, disconnect, notify the operator and rotate affected credentials through a verified route. The separate SSH connection guide covers refusals and timeouts; those network symptoms do not justify accepting a changed host key.
Frequently asked questions
Is the key change normal after reinstalling a VPS? It can be, but verify the new fingerprint out of band before accepting it.
Can I use ssh-keyscan alone as proof? It retrieves what the network currently presents. Compare that result with a trusted operator or pre-recorded fingerprint before making a trust decision.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.