Empreinte SSH changée : rétablir l’accès SFTP à WordPress après vérification

Reconnaître une identité de serveur différente

Après une migration ou une intervention d’hébergement, votre client SFTP refuse la connexion et annonce que la clé d’hôte a changé. Avec OpenSSH, le message peut commencer par « REMOTE HOST IDENTIFICATION HAS CHANGED ». WinSCP peut signaler que la clé du serveur ne correspond plus à celle mémorisée. Ce refus intervient avant la maintenance des fichiers WordPress.

La clé d’hôte identifie le serveur SSH. Son empreinte est une représentation courte utilisée pour la comparer. Elle ne correspond ni à votre mot de passe WordPress, ni à votre clé privée de connexion, ni au certificat HTTPS du site. Changer ces autres éléments ne corrige donc pas ce contrôle d’identité.

Une migration peut expliquer un changement légitime, mais elle ne le prouve pas. Le résultat recherché est une connexion vers le bon serveur dont l’empreinte a été confirmée, puis une mémorisation limitée à cette cible. Il faut vérifier avant de remplacer l’entrée connue. Accepter simplement la nouvelle clé pour faire disparaître l’alerte supprimerait l’indice précisément destiné à signaler une mauvaise destination.

Vérifier le protocole, l’hôte et le port du profil

Dans le profil de connexion existant, relevez le protocole, le nom d’hôte et le port. Le serveur SFTP fourni par l’hébergeur peut porter un nom différent du domaine public de WordPress. Une migration du site n’implique pas forcément que l’ancien nom de serveur technique pointe maintenant au bon endroit.

Distinguez SFTP, qui s’appuie sur SSH, de FTP ou FTPS. Un message de certificat TLS relève d’un autre contrôle. Vérifiez aussi si le profil utilise un alias, une adresse IP, un proxy ou un passage par un autre hôte. La même adresse affichée dans un contrat ne suffit pas si le client emploie encore une ancienne cible enregistrée.

Sur WordPress.com ou une autre plateforme gérée, utilisez uniquement les paramètres SFTP proposés pour le site et le compte autorisés. Ce parcours suppose que cet accès existe déjà ; il ne crée pas un accès SFTP et n’ouvre pas une console SSH qui ne serait pas prévue par le service.

1. Ouvrez les paramètres du profil sans lancer de transfert et notez hôte, port et protocole.
2. Comparez-les aux informations actuelles de l’espace d’hébergement déjà connu.
3. Relevez l’algorithme et l’empreinte présentés par l’alerte, ainsi que sa date.
4. Conservez le nom du client et, s’il le précise, le fichier local contenant l’ancienne entrée.
5. Si la cible est erronée, corrigez d’abord le profil ; ne remplacez pas la confiance d’un autre serveur pour conserver une mauvaise adresse.

Obtenir l’empreinte attendue par un canal fiable

Demandez au responsable du serveur l’empreinte de sa clé d’hôte pour le nom et le port exacts. Utilisez le panneau d’hébergement authentifié déjà connu, un échange d’assistance ouvert depuis cet espace ou une autre voie de confiance établie. Une information fournie uniquement par la connexion qui vient d’être contestée ne constitue pas une confirmation indépendante.

Comparez l’algorithme et la valeur complète dans le même format, par exemple SHA-256. Deux formats d’empreinte différents ne se comparent pas caractère par caractère comme s’ils étaient identiques. Si plusieurs clés sont prévues, demandez leur liste autorisée et la raison de cette pluralité.

L’empreinte provient de la partie publique de la clé d’hôte ; vous n’avez pas à demander la clé privée du serveur ni à transmettre la vôtre pour ce contrôle. Conservez la confirmation, sa date et la cible concernée dans votre dossier de maintenance. Si le responsable ne confirme pas la nouvelle valeur ou si une partie diffère, interrompez ce parcours de remplacement et faites vérifier la destination avant d’envoyer des identifiants ou des fichiers.

Lire une empreinte depuis une console serveur indépendante

Si vous administrez vous-même un serveur Linux et disposez d’une console de confiance fournie par l’hébergement, vous pouvez y lire l’empreinte de sa clé publique. Cette voie ne consiste pas à ouvrir d’abord la connexion SSH contestée pour lui demander de confirmer sa propre identité.

Le chemin ci-dessous est un exemple courant pour une clé Ed25519. Le responsable doit confirmer qu’il s’agit bien du fichier public correspondant à la clé utilisée par le service SSH de cette cible. Une autre configuration peut employer un autre chemin ou plusieurs clés. La commande affiche une empreinte ; elle ne crée ni ne remplace de clé.

Comparez le résultat avec la valeur présentée au client, pour le même algorithme et le même format. Si le fichier, la configuration et le service actif ne concordent pas, faites examiner l’intervention serveur avant de changer la confiance locale. N’exécutez pas une commande de génération de clés pour réparer le seul avertissement du client : elle pourrait créer un nouveau changement pour tous les utilisateurs.

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

Préserver les informations de confiance avant modification

Conservez en privé le profil de connexion, l’ancienne empreinte connue, la nouvelle valeur confirmée et la justification du changement. Ce relevé permet de revenir sur une modification erronée et de distinguer plusieurs serveurs au prochain incident. Les fichiers de confiance peuvent contenir les noms d’autres systèmes ; ne les publiez pas intégralement.

Pour OpenSSH, identifiez le fichier réellement utilisé. Le fichier utilisateur habituel est ~/.ssh/known_hosts sur un système de type Unix, souvent dans le dossier .ssh du compte sous Windows. Le message d’erreur ou la configuration peut désigner un autre emplacement. Faites une copie privée de ce fichier local avant un retrait d’entrée, avec ses permissions conservées.

WinSCP utilise son propre stockage de configuration. Modifier known_hosts d’OpenSSH ne met pas automatiquement à jour son cache, et l’inverse n’est pas garanti. Choisissez donc le parcours du client qui produit l’alerte au lieu d’appliquer successivement toutes les méthodes. Aucun changement des fichiers ou de la base WordPress n’est nécessaire à ce stade : la correction concerne l’identité de la destination et sa mémorisation locale.

Rechercher l’entrée OpenSSH correspondant à la cible

Cette approche convient si l’alerte provient du client OpenSSH et si vous connaissez le fichier de confiance utilisé. La commande de recherche ci-dessous vise un port non standard illustratif, 2222. Remplacez le nom, le port et le chemin du fichier par les valeurs réellement observées.

Pour le port standard, la cible est généralement le nom d’hôte sans la forme entre crochets et port ; suivez la forme enregistrée et la configuration du client. Une adresse IP ou un alias peut également avoir sa propre entrée. La recherche sait retrouver les noms hachés, qui ne sont pas lisibles comme un simple domaine dans le fichier. L’option -l demande l’affichage des empreintes des clés trouvées.

Les exemples de chemins utilisent la notation Unix. Avec OpenSSH sous Windows, exécutez la commande dans PowerShell et remplacez le chemin par le fichier local cité par l’alerte, entre guillemets ; ne collez pas ces lignes dans une console PHP ni dans les commandes du serveur distant. Si la confiance provient d’un fichier système géré, confiez sa correction au responsable plutôt que de le remplacer par votre fichier utilisateur.

1. Confirmez que vous travaillez sur le fichier local cité par l’alerte et sauvegardé à l’étape précédente.
2. Lancez la recherche pour la seule cible concernée.
3. Comparez les entrées trouvées au profil et aux empreintes autorisées.
4. Si aucune entrée ne correspond, vérifiez alias, port et emplacement avant tout retrait.
5. Si plusieurs clés sont légitimes pour cette cible, faites préparer leur gestion ciblée plutôt qu’un effacement de toutes ses références.

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

Retirer une ancienne entrée OpenSSH seulement après confirmation

Si le responsable a confirmé le remplacement de l’ancienne clé pour cette cible et que sa nouvelle empreinte est connue, vous pouvez retirer les anciennes références correspondantes dans le fichier identifié. ssh-keygen -R retire toutes les clés de cette cible dans ce fichier ; ce n’est pas un effacement limité à une ligne ou à un seul algorithme.

N’utilisez donc pas ce retrait global pour une cible qui doit conserver plusieurs clés légitimes sans préparation du mainteneur. L’exemple reprend la même cible et le même fichier que la recherche précédente. Il modifie ce fichier local, après sauvegarde ; il ne répare pas le serveur.

1. Vérifiez une dernière fois le nom, le port, le fichier et la confirmation indépendante de la nouvelle empreinte.
2. Lancez uniquement le retrait correspondant à cette cible.
3. Recommencez ensuite la connexion habituelle vers le même hôte et le même port.
4. À la nouvelle demande de confiance, comparez la valeur complète à la confirmation obtenue avant de l’accepter.
5. Si une autre valeur est présentée, annulez. Ne retirez pas d’autres entrées pour essayer de faire passer la connexion.

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

Actualiser la clé dans WinSCP déjà utilisé

WinSCP est un client de transfert gratuit pour Windows. Cette voie s’adresse aux personnes qui l’utilisent déjà ; il n’est pas nécessaire de l’installer pour modifier le fichier de confiance d’un autre client. Dans sa fenêtre de connexion, vérifiez les champs File protocol, Hostname et Port number du profil concerné.

Après comparaison indépendante de l’empreinte, le dialogue de changement permet de remplacer une référence devenue obsolète avec Update. Lorsque plusieurs serveurs ou clés légitimes doivent être conservés pour la même destination, Add répond à un autre besoin et doit être utilisé seulement avec la liste confirmée. La traduction des libellés peut varier.

1. Ouvrez le profil existant et confirmez la cible sans lancer de transfert de fichiers.
2. Relisez l’empreinte et l’algorithme présentés dans l’avertissement.
3. Comparez-les à la valeur reçue par le canal fiable.
4. Choisissez Update pour le remplacement confirmé, ou Add uniquement pour une clé supplémentaire autorisée à conserver avec les autres.
5. Annulez si la comparaison échoue. Une fois la session vérifiée, Tabs > Server/protocol Information permet de retrouver les empreintes utilisées ; les lire après une acceptation non vérifiée ne prouverait pas rétroactivement la bonne identité.

Prévoir plusieurs serveurs ou une autorité de confiance

Une destination peut répartir les connexions entre plusieurs serveurs SSH. Si leurs clés diffèrent, une connexion peut présenter une valeur puis la suivante une autre. Cela exige une liste d’empreintes autorisées ou une architecture de confiance adaptée, pas des acceptations répétées sans contrôle.

Demandez quelles clés sont attendues pour cette destination et comment le client doit les conserver. Sur WinSCP, l’ajout documenté permet de garder plusieurs clés. Avec OpenSSH, le responsable doit gérer les références prévues dans le fichier approprié ; la commande de retrait présentée plus haut supprimerait toutes celles de la cible sélectionnée.

Certaines organisations utilisent des certificats de clés d’hôte signés par une autorité de confiance. Un changement d’autorité demande alors un contrôle de cette politique, pas simplement le remplacement d’une empreinte de clé brute. Si l’alerte mentionne une autorité ou une configuration centralisée, faites intervenir son responsable. Ce guide ne propose pas de modifier cette confiance globale pour un seul compte WordPress. Conservez le lien entre destination, liste autorisée et mode de gestion afin que le prochain changement soit préparé avant de bloquer les utilisateurs.

Mettre à jour séparément une automatisation existante

Un transfert automatisé peut conserver une empreinte attendue dans son script ou sa configuration. Corriger le profil graphique ne suffit pas si la tâche utilise un autre compte système, un stockage distinct ou une valeur explicitement épinglée. Le journal doit permettre d’identifier ce contexte sans exposer les identifiants.

Dans une automatisation WinSCP, le paramètre -hostkey peut définir la clé attendue. Après vérification indépendante, le responsable remplace seulement la valeur obsolète dans la définition réellement utilisée. Il ne doit pas la remplacer par un joker acceptant toute clé, ni supprimer le contrôle pour laisser la tâche continuer.

Préparez d’abord un essai de connexion et de consultation sans transfert métier. Conservez le script précédent en privé, ses paramètres de cible et le compte qui l’exécute. Si un transfert a déjà été tenté, vérifiez les fichiers reçus avant de relancer une opération qui peut écraser ou importer des données. L’empreinte confirme l’identité du serveur, pas l’innocuité de la commande exécutée ensuite. Une fois le contexte validé, reprenez le job selon son mécanisme habituel et contrôlez son résultat plutôt que d’exécuter une seconde copie en parallèle.

Contrôler la connexion avant toute modification WordPress

Après mémorisation de la valeur vérifiée, connectez-vous au profil attendu et commencez par consulter la liste des dossiers. Confirmez que vous retrouvez l’environnement visé, par exemple la bonne racine ou la copie de travail prévue. Une authentification réussie ne signifie pas automatiquement que ce compte ouvre le dossier WordPress que vous souhaitiez maintenir.

N’effectuez pas un téléversement de wp-config.php ou une restauration pour tester simplement l’accès. Une consultation suffit d’abord. Si le serveur est correctement identifié mais refuse l’authentification ou l’accès à un répertoire, traitez ce nouveau message séparément ; changer encore la clé mémorisée ne corrigera pas un droit de fichier ou un identifiant utilisateur.

1. Comparez l’empreinte de la session à la valeur confirmée.
2. Vérifiez l’hôte, le port et le compte utilisés.
3. Consultez le dossier prévu sans modifier de fichier et contrôlez qu’il correspond au bon site.
4. Fermez puis rouvrez une session lorsque cela est adapté, pour vérifier que la confiance retenue est bien conservée.
5. Pour une automatisation, contrôlez également son contexte et sa propre valeur attendue. Consignez le succès de connexion séparément du résultat du prochain transfert.

Conserver le refus si l’identité ne peut pas être confirmée

Si personne ne confirme la nouvelle empreinte, si elle diffère de la valeur annoncée ou si l’hôte résout vers une destination inattendue, gardez la connexion interrompue. Transmettez au responsable la cible, le port, l’algorithme, les deux valeurs disponibles et la date du changement. Il doit vérifier le serveur, le routage ou la migration concernés.

Ne remplacez pas cette étape par une collecte de clé sur le même réseau puis son acceptation automatique. Un outil qui interroge simplement la clé présentée observe une valeur ; il n’en établit pas l’identité attendue. Ne désactivez pas non plus la vérification stricte du client pour continuer la maintenance.

Si des identifiants ont déjà été envoyés à une destination finalement jugée incorrecte, faites traiter cet accès avec le responsable du compte et du serveur. La suite dépend des éléments réellement exposés ; elle ne se résume pas à retirer une ligne locale. Le dossier de vérification doit préciser ce qui a été observé, ce qui a été confirmé par une autre voie et ce qui reste inconnu. Une ancienne opération de migration ne justifie pas de transformer cette inconnue en confiance permanente.

Annuler un changement local et documenter la rotation

Si vous avez modifié le mauvais profil, rétablissez ses paramètres précédents et interrompez la connexion incorrecte. Pour un fichier de confiance local, comparez la sauvegarde et les changements intervenus depuis avant de restaurer une ancienne version complète. Celle-ci pourrait effacer d’autres références légitimement ajoutées entre-temps.

Rétablir une ancienne entrée ne rend pas une nouvelle clé valide. Si le serveur a réellement changé, le client peut de nouveau refuser la connexion tant que la bonne identité n’a pas été confirmée et mémorisée. Ce refus est cohérent ; il ne faut pas le supprimer par une option d’acceptation générale pour rendre le retour arrière plus confortable.

Conservez la date, l’ancienne et la nouvelle empreinte, la cible précise, la confirmation du prestataire et les clients ou tâches actualisés. Pour une prochaine migration, demandez à l’avance les nouvelles informations SFTP et la procédure de rotation des clés. Aucun plugin WordPress n’est nécessaire pour ce travail : il concerne le client de connexion et le serveur SSH. Une trace de maintenance claire permet de rétablir l’accès sans toucher aux contenus du site ni affaiblir la vérification d’identité.