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. This issue is particularly important from a security perspective because host key warnings can indicate man-in-the-middle attacks or DNS hijacking.

The problem commonly appears after server migrations, IP address changes, hostname updates, or when moving between hosting providers. SSH/SFTP clients store known host fingerprints to prevent connecting to the wrong server, and when the legitimate server changes, this security feature can block access until the stored fingerprint is updated.

Symptoms

  • SFTP clients warn that the host key changed after migration with messages like "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED"
  • Users see messages such as host identification changed, fingerprint mismatch, or "possible DNS spoofing" warnings
  • Credentials that used to work now fail because the client refuses to trust the server until the key is accepted
  • 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
  • Error messages reference the old IP address or hostname in the mismatch warning
  • Automated SFTP scripts or scheduled transfers fail silently or with error logs
  • FileZilla, WinSCP, or other clients show warnings about potential security issues

Common Causes

  • The new SFTP server legitimately uses a different SSH host key than the old server
  • The client still has the old server fingerprint cached in known_hosts file or saved-site data
  • DNS for the SFTP hostname still points some users to the old machine due to caching or incomplete cutover
  • A shared hostname, jump host, or proxy path changed during migration, routing through different servers
  • 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 updates
  • Load balancer or failover configuration changed the actual server being reached
  • Different team members have different known_hosts entries from different connection histories

Step-by-Step Fix

  1. 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. Run ssh-keyscan -t rsa new-server.example.com from a trusted location and compare with the server’s actual key file (/etc/ssh/ssh_host_rsa_key.pub).
  2. 2.Check which hostname and IP the failing client is actually reaching by looking at the error message details and running nslookup sftp.example.com, because a host key mismatch is often caused by DNS or bookmark drift rather than by the new server itself.
  3. 3.Compare the presented fingerprint in the warning message with the trusted fingerprint for the destination server, because that tells you whether the warning reflects a legitimate migration change or an unexpected route to the wrong server. If fingerprints match the new server, it’s a normal post-migration update.
  4. 4.Review the client’s saved trust data such as ~/.ssh/known_hosts entries, WinSCP/FileZilla saved sites, or PuTTY’s host key cache, because old SSH trust records survive migrations and block otherwise correct new connections.
  5. 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. For OpenSSH, edit ~/.ssh/known_hosts and remove the old entry; for GUI clients, delete the saved site and recreate it.
  6. 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. Accept the new key when prompted and save it.
  7. 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, indicating DNS issues rather than just known_hosts problems.
  8. 8.Check whether any automation scripts, deployment jobs, or shared SFTP tools also pin the old fingerprint in their own known_hosts files or SSH options (-o StrictHostKeyChecking=no is dangerous but sometimes used), because manual access may be fixed while scheduled transfers still fail.
  9. 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 and having a reference helps distinguish real issues from expected changes.

Verification

Confirm the fix is complete:

  1. 1.Connect via SFTP and verify no warnings appear, only the normal login prompt
  2. 2.Check that the known_hosts entry matches the new server’s fingerprint
  3. 3.Verify file transfers work correctly after accepting the new key
  4. 4.Test from multiple client machines if multiple users access the same server
  5. 5.Verify any automated SFTP scripts run successfully

Prevention

To avoid confusion in future migrations:

  • Document the expected new server fingerprint before migration and communicate it to users
  • Update known_hosts files centrally if possible (configuration management, shared SSH config)
  • Use SSHFP DNS records to allow fingerprint verification via DNS
  • Communicate to users that they should expect and accept a new host key after migration
  • Include host key updates in the migration checklist and user communication
  • For automation, consider using ssh-keyscan to pre-populate known_hosts with the new key
  • Remove old known_hosts entries proactively as part of migration cleanup
  • [Fix Cpanel Account Suspended Inode Limit Exceeded Issue in Hosting](cpanel-account-suspended-inode-limit-exceeded)
  • [Fix Fix Addon Domain Showing Default Site After Cpanel Account Transfer Issue in Hosting](fix-addon-domain-showing-default-site-after-cpanel-account-transfer)
  • [Fix Fix App Still Writing To Old S3 Bucket After Migration Issue in Hosting](fix-app-still-writing-to-old-s3-bucket-after-migration)
  • [Fix Fix CI Pipeline Still Deploying To Old Server After Migration Issue in Hosting](fix-ci-pipeline-still-deploying-to-old-server-after-migration)
  • [Fix Fix Cloudlinux Lve Limit Hits After Cpanel Account Transfer Issue in Hosting](fix-cloudlinux-lve-limit-hits-after-cpanel-account-transfer)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "How to Fix an SFTP Host Key Mismatch After Server Migration", "description": "Resolve an SFTP host key mismatch after migration by checking the new server fingerprint, saved trust entries, DNS targets, and connection path.", "url": "https://www.fixwikihub.com/fix-sftp-host-key-mismatch-after-server-migration", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2025-10-31T07:59:01.770Z", "dateModified": "2025-10-31T07:59:01.770Z" } </script>