SSH fingerprint changed: restore WordPress SFTP access after verification

Recognize a different server identity

After a migration or hosting intervention, your SFTP client refuses the connection and reports that the host key changed. With OpenSSH, the message may begin “REMOTE HOST IDENTIFICATION HAS CHANGED.” WinSCP may report that the server key no longer matches the stored key. This rejection occurs before WordPress file maintenance.

The host key identifies the SSH server. Its fingerprint is a short representation used for comparison. It is neither your WordPress password, your private login key, nor the site’s HTTPS certificate. Changing those other items therefore does not fix this identity check.

A migration may explain a legitimate change, but does not prove it. The goal is a connection to the correct server with a confirmed fingerprint, followed by trust storage limited to that target. Verify before replacing the known entry. Simply accepting the new key to dismiss the alert would remove the very evidence intended to flag an incorrect destination.

Check the profile’s protocol, host, and port

In the existing connection profile, record the protocol, hostname, and port. The host-provided SFTP server may have a name different from the public WordPress domain. Migrating the site does not necessarily mean the old technical server name now points to the correct place.

Distinguish SFTP, which uses SSH, from FTP or FTPS. A TLS certificate message belongs to a different check. Also verify whether the profile uses an alias, IP address, proxy, or another host as a jump point. The same address appearing in a contract is insufficient if the client still uses an old saved target.

On WordPress.com or another managed platform, use only SFTP parameters provided for the authorized site and account. This procedure assumes that access already exists; it does not create SFTP access or open an SSH console not provided by the service.

1. Open profile settings without starting a transfer and record host, port, and protocol.
2. Compare them with current information in the hosting account you already know.
3. Record the algorithm and fingerprint shown by the alert, along with its date.
4. Keep the client name and, if specified, the local file containing the old entry.
5. If the target is wrong, correct the profile first; do not replace trust for another server to retain an incorrect address.

Obtain the expected fingerprint through a trusted channel

Ask the server administrator for its host-key fingerprint for the exact name and port. Use the already-known authenticated hosting panel, a support conversation opened from that account, or another established trusted channel. Information supplied only through the connection just challenged is not independent confirmation.

Compare the algorithm and complete value in the same format, such as SHA-256. Two different fingerprint formats cannot be compared character by character as if identical. If multiple keys are intended, request their authorized list and the reason for having several.

The fingerprint comes from the public part of the host key; you do not need to request the server’s private key or send yours for this check. Keep the confirmation, date, and target in your maintenance record. If the administrator does not confirm the new value or any part differs, stop this replacement procedure and have the destination checked before sending credentials or files.

Read a fingerprint from an independent server console

If you administer a Linux server yourself and have a trusted console provided by hosting, you can read its public-key fingerprint there. This does not mean first opening the challenged SSH connection to ask it to confirm its own identity.

The path below is a common example for an Ed25519 key. The administrator must confirm that it is the public file corresponding to the key used by this target’s SSH service. Another configuration may use a different path or several keys. The command displays a fingerprint; it creates or replaces no key.

Compare the result with the client-presented value for the same algorithm and format. If the file, configuration, and active service do not match, have the server intervention examined before changing local trust. Do not run a key-generation command to fix only the client warning: it might create a new change for every user.

ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ed25519_key.pub

Preserve trust information before changing it

Privately retain the connection profile, old known fingerprint, newly confirmed value, and reason for the change. This record lets you revisit an incorrect change and distinguish servers during the next incident. Trust files may contain other systems’ names; do not publish them in full.

For OpenSSH, identify the file actually used. The usual user file is ~/.ssh/known_hosts on a Unix-like system, often in the account’s .ssh directory on Windows. The error message or configuration may point elsewhere. Make a private copy of this local file before removing an entry, preserving permissions.

WinSCP uses its own configuration storage. Changing OpenSSH’s known_hosts does not automatically update its cache, and the reverse is not guaranteed. Therefore choose the procedure for the client producing the alert instead of applying every method in succession. No WordPress file or database change is needed at this stage: the correction concerns destination identity and its local storage.

Find the OpenSSH entry matching the target

This approach is appropriate if the alert comes from OpenSSH and you know the trust file used. The lookup command below targets an illustrative nonstandard port, 2222. Replace the name, port, and file path with the values actually observed.

For the standard port, the target is generally the hostname without the bracket-and-port form; follow the recorded form and client configuration. An IP address or alias may also have its own entry. Lookup can find hashed names, which are not readable as plain domains in the file. The -l option requests fingerprints for the keys found.

The path examples use Unix notation. With OpenSSH on Windows, run the command in PowerShell and replace the path with the local file named in the alert, in quotes; do not paste these lines into a PHP console or remote-server commands. If trust comes from a managed system file, leave its correction to the administrator instead of replacing it with your user file.

1. Confirm that you are working on the local file named in the alert and backed up in the previous step.
2. Run lookup only for the affected target.
3. Compare found entries with the profile and authorized fingerprints.
4. If no entry matches, check alias, port, and location before removing anything.
5. If several keys are legitimate for this target, have targeted management prepared instead of erasing all references.

ssh-keygen -F '[sftp.votre-hebergeur.example]:2222' -l -f '/chemin/local/vers/known_hosts'

Remove an old OpenSSH entry only after confirmation

If the administrator confirmed replacement of the old key for this target and the new fingerprint is known, you can remove the corresponding old references from the identified file. ssh-keygen -R removes every key for that target in this file; it is not limited to one line or algorithm.

Therefore do not use this broad removal for a target that must retain several legitimate keys without maintainer preparation. The example uses the same target and file as the preceding lookup. It modifies that local file after backup; it does not repair the server.

1. Check the name, port, file, and independent confirmation of the new fingerprint one final time.
2. Run only removal corresponding to this target.
3. Then retry the usual connection to the same host and port.
4. At the new trust prompt, compare the complete value with the confirmation obtained before accepting it.
5. If another value is presented, cancel. Do not remove other entries to try to make the connection work.

ssh-keygen -R '[sftp.votre-hebergeur.example]:2222' -f '/chemin/local/vers/known_hosts'

Update the key in an already-used WinSCP

WinSCP is a free transfer client for Windows. This approach is for people already using it; there is no need to install it to change another client’s trust file. In its login window, check the affected profile’s File protocol, Hostname, and Port number fields.

After independent fingerprint comparison, the change dialog allows an obsolete reference to be replaced with Update. When several legitimate servers or keys must be retained for the same destination, Add serves a different need and should be used only with the confirmed list. Translated labels may vary.

1. Open the existing profile and confirm the target without starting a file transfer.
2. Reread the fingerprint and algorithm shown in the warning.
3. Compare them with the value received through the trusted channel.
4. Choose Update for a confirmed replacement, or Add only for an authorized additional key to retain with the others.
5. Cancel if comparison fails. Once the session is verified, Tabs > Server/protocol Information lets you find the fingerprints used; reading them after unverified acceptance would not retroactively prove the correct identity.

Account for multiple servers or a trusted authority

A destination may distribute connections across several SSH servers. If their keys differ, one connection may present one value and the next another. This requires an authorized fingerprint list or appropriate trust architecture, not repeated unchecked acceptance.

Ask which keys are expected for this destination and how the client should retain them. In WinSCP, documented addition allows several keys to be kept. With OpenSSH, the administrator must manage intended references in the appropriate file; the removal command above would delete all references for the selected target.

Some organizations use host-key certificates signed by a trusted authority. An authority change then requires checking that policy, not simply replacing a raw-key fingerprint. If the alert mentions an authority or centralized configuration, involve its administrator. This guide does not propose changing that global trust for a single WordPress account. Preserve the connection between destination, authorized list, and management method so the next change is prepared before blocking users.

Update existing automation separately

An automated transfer may retain an expected fingerprint in its script or configuration. Correcting the graphical profile is insufficient if the task uses another system account, separate storage, or an explicitly pinned value. The log should identify this context without exposing credentials.

In WinSCP automation, the -hostkey parameter may define the expected key. After independent verification, the administrator replaces only the obsolete value in the definition actually used. Do not replace it with a wildcard accepting every key or remove verification to let the task continue.

First prepare a connection and browsing test without a business transfer. Keep the previous script private, along with its target parameters and execution account. If a transfer was already attempted, check received files before rerunning an operation that may overwrite or import data. The fingerprint confirms server identity, not the harmlessness of the command executed afterward. Once the context is validated, resume the job through its usual mechanism and check its result instead of running a second copy in parallel.

Check the connection before any WordPress change

After storing the verified value, connect to the intended profile and start by browsing the directory list. Confirm the intended environment, such as the correct root or planned working copy. Successful authentication does not automatically mean the account opens the WordPress directory you meant to maintain.

Do not upload wp-config.php or perform a restore merely to test access. Browsing is enough initially. If the server is correctly identified but rejects authentication or directory access, handle that new message separately; changing the stored key again will not fix file permissions or a user identifier.

1. Compare the session fingerprint with the confirmed value.
2. Check the host, port, and account used.
3. Browse the intended directory without changing files and verify that it matches the correct site.
4. Close and reopen a session where appropriate to check that the chosen trust is retained.
5. For automation, also check its context and its own expected value. Record connection success separately from the next transfer’s result.

Keep the rejection if identity cannot be confirmed

If nobody confirms the new fingerprint, it differs from the announced value, or the host resolves to an unexpected destination, keep the connection stopped. Send the administrator the target, port, algorithm, both available values, and change date. The administrator must check the affected server, routing, or migration.

Do not replace this step by collecting a key over the same network and automatically accepting it. A tool merely querying the presented key observes a value; it does not establish the expected identity. Do not disable the client’s strict verification to continue maintenance either.

If credentials were already sent to a destination ultimately deemed incorrect, have that access addressed with the account and server administrators. Next steps depend on what was actually exposed; they are not limited to removing a local line. The verification record must state what was observed, what was confirmed through another channel, and what remains unknown. An earlier migration does not justify turning that uncertainty into permanent trust.

Undo a local change and document the rotation

If you changed the wrong profile, restore its previous parameters and stop the incorrect connection. For a local trust file, compare the backup with intervening changes before restoring an old complete version. It could erase other references legitimately added in the meantime.

Restoring an old entry does not validate a new key. If the server really changed, the client may again reject the connection until the correct identity is confirmed and stored. That rejection is consistent; do not remove it through a general-acceptance option merely to make rollback easier.

Keep the date, old and new fingerprints, exact target, provider confirmation, and clients or tasks updated. For the next migration, request new SFTP information and the key-rotation procedure in advance. No WordPress plugin is needed for this work: it concerns the connection client and SSH server. A clear maintenance record restores access without touching site content or weakening identity verification.

Prepare the comparison record before clicking Update

Gather six items side by side: SFTP protocol, exact hostname, port, key algorithm, complete fingerprint in the same format, and independent channel confirming it. Add the confirmation date and affected profile. These are identity references, not account passwords.

Do not compare only the beginning or end of a fingerprint. Nor should you compare an Ed25519 key with an RSA fingerprint as if they were the same value. If the administrator confirms several keys for a distributed destination, explicitly retain each with its algorithm; adding an authorized key and replacing an old key are different decisions.

In WinSCP, first cancel the dialog if this record is incomplete. After confirmation, reopen the same profile and reread the presented fingerprint before Update or Add according to the established case. Then check only the expected directory, without transferring. If the value still differs, retain the rejection and ask the provider to check routing or rotation. No WordPress change is needed, and buying another client does not prove server identity.