Host key verification failed.

Git l’affiche suivi de « fatal: Could not read from remote repository. ». Le type de clé de la ligne précédente (`ED25519`, `ECDSA`, `RSA`) est celui que le serveur a proposé.

Ce que cela signifie

ssh n’a pas pu confirmer que le serveur est bien celui qu’il prétend être : il a donc abandonné avant l’authentification. Soit l’hôte ne figure pas dans `known_hosts` et ssh n’a pas pu vous demander confirmation (mode batch, CI, commande Git sans terminal), soit il y figure avec une clé différente. La ligne qui précède indique de quel cas il s’agit : « No … host key is known for … » pour un hôte inconnu, un grand avertissement « REMOTE HOST IDENTIFICATION HAS CHANGED » pour un hôte dont la clé a changé.

Pourquoi cela se produit

• Première connexion sans terminal

  fréquente

  Les runners de CI, les tâches cron, les builds Docker et `git` dans des scripts démarrent avec un `known_hosts` vide. Avec `BatchMode yes` ou sans TTY, ssh ne peut pas afficher la demande de confirmation et échoue.

• La clé de l’hôte diffère de celle enregistrée

  fréquente

  Serveur réinstallé, adresse IP réutilisée par une autre machine, répartiteur de charge placé devant des hôtes aux clés différentes, ou bien interception. Consultez l’entrée « REMOTE HOST IDENTIFICATION HAS CHANGED ».

• Le fichier known_hosts n’est pas celui que vous croyez

  occasionnelle

  Un `HOME` différent dans la CI ou sous sudo, un `UserKnownHostsFile` qui pointe ailleurs, ou un fichier appartenant à un autre utilisateur, que ssh ne peut ni lire ni écrire.

Comment corriger l’erreur

1. 1.

   Enregistrer la clé d’hôte après l’avoir vérifiée

   `ssh-keyscan` montre ce que le réseau vous fournit ; comparez son empreinte avec celle d’une source fiable avant de lui faire confiance.

   # Store the server's host key once, after checking its fingerprint out of band.
   ssh-keyscan -t ed25519 server.example.com > /tmp/hostkey
   ssh-keygen -lf /tmp/hostkey          # compare with the fingerprint from your provider/console
   cat /tmp/hostkey >> ~/.ssh/known_hosts

2. 2.

   Fournir à la CI un known_hosts vérifié

   Stockez la ligne vérifiée comme secret ou dans le dépôt. `StrictHostKeyChecking no` ou `ssh-keyscan` au moment de l’exécution font accepter au job n’importe quel serveur qui répond.

   # GitHub Actions: put the verified known_hosts line into a secret, not ssh-keyscan at run time
   - name: Configure SSH
     run: |
       install -d -m 700 ~/.ssh
       echo "${{ secrets.DEPLOY_KNOWN_HOSTS }}" > ~/.ssh/known_hosts
       chmod 600 ~/.ssh/known_hosts

3. 3.

   Utiliser les clés publiées par les hébergeurs Git

   GitHub, GitLab et Bitbucket publient les empreintes de leurs clés d’hôte ; GitHub les fournit aussi via son API meta.

   # GitHub publishes its SSH host keys (also at https://api.github.com/meta, "ssh_keys")
   curl -s https://api.github.com/meta | jq -r '.ssh_keys[] | "github.com " + .' >> ~/.ssh/known_hosts

← Parcourir toute la base de données des erreurs de signature