Introduction

An SFTP connection can fail right after server migration because the client sees a different SSH host key than before. That warning is expected whenever the destination server truly changed, but it can also mean the client is reaching the wrong host, a stale DNS target, or an unexpected jump point. The safe fix is to verify the new server fingerprint first instead of blindly accepting the changed key.

Treat this as an identity-verification problem instead of a general credential issue. Start by proving which server the client is actually reaching and what fingerprint the new SFTP host should present, because the same warning can represent either a normal migration change or a real routing mistake.

Symptoms

  • SFTP clients warn that the host key changed after migration
  • Users see messages such as host identification changed or fingerprint mismatch
  • Credentials that used to work now fail because the client refuses to trust the server
  • One user connects successfully after accepting the new key, while another still sees the old fingerprint warning
  • The site migration is complete, but SFTP access is blocked by trust errors rather than login errors
  • The issue started after server replacement, IP cutover, or hostname migration

Common Causes

  • The new SFTP server legitimately uses a different SSH host key
  • The client still has the old server fingerprint cached in its known-hosts or saved-site data
  • DNS for the SFTP hostname still points some users to the old machine
  • A shared hostname, jump host, or proxy path changed during migration
  • Users are connecting to the wrong saved hostname and comparing the new server against the wrong old key
  • Migration validation covered credentials but not post-cutover SSH host identity

Step-by-Step Fix

  1. Verify the expected fingerprint of the new SFTP server from a trusted admin source, because you should confirm the real host identity before accepting any changed key.
  2. Check which hostname and IP the failing client is actually reaching, because a host key mismatch is often caused by DNS or bookmark drift rather than by the new server itself.
  3. Compare the presented fingerprint with the trusted fingerprint for the destination server, because that tells you whether the warning reflects a legitimate migration change or an unexpected route.
  4. Review the client’s saved trust data such as known-hosts entries or saved-site fingerprints, because old SSH trust records survive migrations and block otherwise correct new connections.
  5. Remove or refresh the saved host key only after confirming the new destination is legitimate, because deleting trust blindly defeats the purpose of the warning.
  6. Reconnect using the intended hostname and verify the client now stores the correct new fingerprint, because the real fix is trust aligned to the destination host you actually want.
  7. Compare results across more than one user or workstation if the behavior differs, because some clients may still resolve the old IP while others already reach the new host.
  8. Check whether any automation scripts, deployment jobs, or shared SFTP tools also pin the old fingerprint, because manual access may be fixed while scheduled transfers still fail.
  9. Document the final hostname, IP, and trusted fingerprint after recovery, because host key changes are a normal but easy-to-misread part of future server migrations.