Host key verification failed.

Git lo imprime seguido de «fatal: Could not read from remote repository.». El tipo de clave de la línea anterior (`ED25519`, `ECDSA`, `RSA`) es el tipo que ofreció el servidor.

Qué significa

ssh no pudo confirmar que el servidor es quien dice ser, así que abortó antes de la autenticación. O bien el host no está en `known_hosts` y ssh no pudo preguntarte (modo por lotes, CI, un comando de Git sin terminal), o bien figura con otra clave. La línea anterior indica cuál de los dos casos es: «No … host key is known for …» para un host desconocido, y una gran advertencia «REMOTE HOST IDENTIFICATION HAS CHANGED» para uno que cambió.

Por qué ocurre

• Primera conexión sin terminal

  frecuente

  Los ejecutores de CI, las tareas de cron, las compilaciones de Docker y `git` dentro de scripts empiezan con un `known_hosts` vacío. Con `BatchMode yes` o sin TTY, ssh no puede mostrar la pregunta de confirmación y falla.

• La clave del host difiere de la registrada

  frecuente

  Un servidor reinstalado, una dirección IP reutilizada por otra máquina, un balanceador de carga delante de hosts con claves distintas o, también, una interceptación. Consulta la entrada «REMOTE HOST IDENTIFICATION HAS CHANGED».

• El archivo known_hosts no es el que crees

  ocasional

  Un `HOME` distinto en la CI o con sudo, un `UserKnownHostsFile` que apunta a otro sitio o un archivo de otro usuario que ssh no puede leer ni escribir.

Cómo solucionarlo

1. 1.

   Registrar la clave del host después de verificarla

   `ssh-keyscan` muestra lo que te da la red; compara su huella digital con una procedente de una fuente de confianza antes de confiar en ella.

   # 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.

   Proporcionar a la CI un known_hosts verificado

   Guarda la línea verificada como secreto o en el repositorio. `StrictHostKeyChecking no` o `ssh-keyscan` en tiempo de ejecución hacen que el trabajo acepte cualquier cosa que responda.

   # 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.

   Usar las claves publicadas por los proveedores de alojamiento Git

   GitHub, GitLab y Bitbucket publican las huellas digitales de sus claves de host; GitHub, también a través de su 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

← Explorar toda la base de datos de errores de firma