¿Por qué las conexiones a GitHub a través de SSH arrojan el error “Advertencia: la identificación del host remoto ha cambiado”?

12 minutos de lectura

Avatar de usuario de Dheeraj Vepakomma
Dheeraj Vepakomma

Hace un tiempo comencé a recibir esta advertencia cuando presioné a GitHub.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.

¿Es esto normal y cómo lo soluciono?

  • ssh-keygen -R github.com – este comando no actualiza las claves ssh anteriores (su ~/.ssh/id_rsa & ~/.ssh/id_rsa.pub permanecerá sin cambios).

    –Constantin De La Roche

    27 de marzo a las 7:11

Avatar de usuario de Dheeraj Vepakomma
Dheeraj Vepakomma

Esto sucedió porque el 24 de marzo de 2023, GitHub actualizó su clave de host RSA SSH se utiliza para proteger las operaciones de Git para GitHub.com porque la clave privada se expuso brevemente en un repositorio público de GitHub. Recibirá ese mensaje si recordó la huella digital de la clave anterior de GitHub en su cliente SSH antes de esa fecha.

Según la publicación del blog vinculada, la solución es eliminar la clave anterior ejecutando este comando:

$ ssh-keygen -R github.com

ahora el siguiente git conexión (extracción, inserción o clonación) debería preguntarle si confía en la nueva clave SSH. Antes de entrar yesasegúrese de que la nueva clave que se muestra sea válida, utilizando la lista:

https://docs.github.com/en/authentication/mantener-su-cuenta-y-datos-seguros/githubs-ssh-key-fingerprints

Referirse a entrada en el blog para conocer otras formas de solucionar el problema.

  • Usando Git Bash en Windows, descubrí que el comando anterior funcionaba, pero en git push Recibí un mensaje de que “no se puede establecer la autenticidad de github.com”. Cuando me preguntaron si quería continuar, escribí “sí” y ahora todo vuelve a funcionar.

    – AlainD

    24 de marzo a las 12:31

  • @AlainD: eso se esperaba, porque este comando básicamente solo dice “olvidar la clave pública anterior” y se confiará en la nueva la próxima vez. Si desea estar en lo correcto al respecto, es mejor guardar el nuevo y correcto conocido con anticipación (la publicación del blog le indica cómo).

    – Joaquín Sauer

    24 de marzo a las 13:24

  • Tenía una clave RSA antigua para ssh.github.com además de github.com los que se esconden en ~/.ssh/known_hosts. Quita eso si lo ves; se actualizará después de que escriba “sí” como lo describe @AlainD.

    –Jacob Crofts

    24 de marzo a las 18:51

  • El $ ssh-keygen -R github.com el comando funciona para mí, luego acepte la solicitud de conexión para usar el comando git push. ¡Gracias!

    – Gurú Bhandari

    25 de marzo a las 21:42

  • @amr ese es el mensaje cuando no hay registro del mismo.

    – perro naranja

    27 de marzo a las 10:47

Según Github entrada en el blogsu clave SSH se filtró y, por lo tanto, regeneraron su clave.

Debe eliminar su clave almacenada ejecutando:

$ ssh-keygen -R github.com

Lo que debería generar algo como:

# Host github.com found: line 1
.ssh/known_hosts updated.

Seguido de un comando para obtener su nueva clave:

$ curl -L https://api.github.com/meta | jq -r '.ssh_keys | .[]' | sed -e 's/^/github.com /' >> ~/.ssh/known_hosts

Una vez completado, puede volver a ejecutar el git comando que estaba intentando.

  • NO FUNCIONA… DANDO ERROR. $ rizo -L api.github.com/meta | jq -r ‘.ssh_claves | .[]’ | sed -e ‘s/^/github.com /’ >> ~/.ssh/known_hosts bash: jq: command not found % Total % Received % Xferd Average Speed ​​Time Time Time Current Dload Upload Total Gast Left Speed ​​0 0 0 0 0 0 0 0 –:–:– 0:00:07 –:–:– 0 curl: (60) Problema con el certificado SSL: no se pudo obtener el certificado del emisor local Más detalles aquí: curl.haxx.se/docs/sslcerts.html

    – Kamlesh

    26 de marzo a las 9:00

  • curl no pudo verificar la legitimidad del servidor y, por lo tanto, no pudo establecer una conexión segura con él. Para obtener más información sobre esta situación y cómo solucionarla, visite la página web mencionada anteriormente.

    – Kamlesh

    26 de marzo a las 9:01

  • @Kamlesh posiblemente falta la biblioteca jq de su lado, intente ejecutar esto para instalarlo: brew install jq. Necesitarás tener un brebaje instalado también (cerveza.sh).

    – Nikitahl

    27 de marzo a las 9:23

Avatar de usuario de Dishant Walia
Dishant Walia

Desde Github:

Aproximadamente a las 05:00 UTC del 24 de marzo [2023], por precaución, reemplazamos nuestra clave de host RSA SSH utilizada para asegurar las operaciones de Git para GitHub.com. Hicimos esto para proteger a nuestros usuarios de cualquier posibilidad de que un adversario se hiciera pasar por GitHub o espiara sus operaciones de Git a través de SSH. Esta clave no otorga acceso a la infraestructura de GitHub ni a los datos del cliente. Este cambio solo afecta las operaciones de Git sobre SSH usando RSA. El tráfico web a GitHub.com y las operaciones HTTPS Git no se ven afectados.

SOLUCIÓN: Eliminar la antigua clave RSA SSH de github de .ssh/known_hosts y actualizar la nueva.
https://github.blog/2023-03-23-actualizamos-nuestra-clave-de-host-rsa-ssh/#lo-que-puede-hacer

avatar de usuario de bk2204
bk2204

Sí, GitHub actualizó su clave de host RSA como se menciona en su publicación de blog. Puede seguir las instrucciones allí para actualizar sus claves.

Sin embargo, algunas personas descubren que OpenSSH también ha guardado la clave de host para las direcciones IP a través de la CheckHostIP opción. Esto estaba habilitado de forma predeterminada antes de OpenSSH 8.5, pero tiende a ser inútil ya que dificulta la rotación, por lo que estaba deshabilitado en esa versión. Dicho esto, se puede solucionar así (en Linux y Git Bash):

$ sed -i -e '/AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31\/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi\/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==/d' ~/.ssh/known_hosts

y así en macOS:

$ sed -i '' -e '/AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31\/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi\/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==/d' ~/.ssh/known_hosts

Eso elimina la clave donde sea que se encuentre, ya sea para nombres de host o direcciones IP. Dado que GitHub usa varias direcciones IP, no es realmente posible enumerarlas todas y eliminarlas todas con ssh-keygenpor lo que eliminar la clave manualmente es la mejor opción.

Luego puede seguir las instrucciones de la publicación del blog para actualizar las claves automáticamente:

$ curl -L https://api.github.com/meta | jq -r '.ssh_keys | .[]' | \
  sed -e 's/^/github.com /' >> ~/.ssh/known_hosts

Avatar de usuario de Gabriel Staples
grapas gabriel

En Ubuntu 20.04, usando una clave ed25519 en Github, incluso después de ejecutar ssh-keygen -R github.comsegún la respuesta principal, seguía viendo estas notificaciones cada vez que ejecutaba git push:

$ git push
Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '140.82.112.4'
Offending key for IP in /home/gabriel/.ssh/known_hosts:14
Matching host key in /home/gabriel/.ssh/known_hosts:15
Are you sure you want to continue connecting (yes/no)? yes
Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '140.82.112.4'
Offending key for IP in /home/gabriel/.ssh/known_hosts:14
Matching host key in /home/gabriel/.ssh/known_hosts:15
Are you sure you want to continue connecting (yes/no)? yes
Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '140.82.112.4'
Offending key for IP in /home/gabriel/.ssh/known_hosts:14
Matching host key in /home/gabriel/.ssh/known_hosts:15
Are you sure you want to continue connecting (yes/no)? yes

Entonces, finalmente me quité mi ~/.ssh/known_hosts archivo renombrándolo así:

(Actualización: pruebe la respuesta de @ bk2204 en lugar de ejecutar el mv cmd a continuación. Gracias, @Guntram Blohm).

mv ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

…y ahora git push finalmente funciona bien de nuevo! No me importa tener que volver a autenticar todos mis destinos ssh cada vez que uso ssh nuevamente en un servidor en particular, por lo que elimino efectivamente el ~/.ssh/known_hosts el archivo esta bien. Apenas uso ssh, excepto para empujar a GitHub y GitLab de todos modos.

Nota: la primera vez que corrí git push después de eso tuve que escribir yesComo se muestra abajo:

$ git push
The authenticity of host 'github.com (140.82.112.4)' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com,140.82.112.4' (ECDSA) to the list of known hosts.
Everything up-to-date

Antes de escribir yessin embargo, primero verifiqué en el sitio web de GitHub que el SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM la huella digital era correcta y de GitHub. GitHub tiene las huellas dactilares para cada tipo de clave aquí: https://docs.github.com/en/authentication/mantener-su-cuenta-y-datos-seguros/githubs-ssh-key-fingerprints

Estas son las huellas dactilares de la clave pública de GitHub:

  • SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s (RSA)
  • SHA256:br9IjFspm1vxR3iA35FWE+4VTyz1hYVLIE2t1/CeyWQ (DSA – en desuso)
  • SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM (ECDSA)
  • SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU (Ed25519)

  • Esta podría ser una solución si no está usando ssh para nada más, pero si tiene otros servidores a los que se conecta, esto significa que cualquier cambio en sus claves pasará desapercibido. (Y obviamente tienes algunos otros ya que las claves están en las líneas 14 y 15 de tu known_hosts. Mejor elimine la clave como en la respuesta de @ bk2204, o anote el número de línea (14 en su caso) y elimine la línea 14 manualmente.

    -Guntram Blohm

    24 de marzo a las 21:24

  • HTTPS y SSH usan diferentes claves privadas. La clave privada HTTPS no se filtró, solo la clave privada SSH.

    – JBYoshi

    24 de marzo a las 22:01

  • @JBYoshi, veo varios votos a favor en su comentario, entonces, ¿puede explicar más sobre lo que eso significa y cómo es pertinente? No entiendo lo que me está diciendo o si está indicando que debería hacer algo diferente, pero quiero aprender más.

    – Gabriel grapas

    25 de marzo a las 19:57

  • Gabriel, JBYoshi le está respondiendo a Davislor, quien insinuó que hubo una circularidad al verificar las huellas dactilares con la llave que estás tratando de verificar. En realidad, está verificando claves SSH con huellas dactilares verificadas a través de HTTPS, que no se vieron afectadas por la filtración. Así que no hay circularidad. Todo está bien.

    -Luca Citi

    26 de marzo a las 1:54

  • Sí, respondieron mi pregunta. Ha habido infracciones en las que alguien “verificó” con una clave o suma de verificación que obtuvo de un sitio que controla el atacante.

    – Davislor

    26 de marzo a las 15:52


Avatar de usuario de Jeff Ward
jeff sala

El blog de github sugiere simplemente:

ssh-keygen -R github.com

Desafortunadamente, no es tan fácil y sigo recibiendo errores como los siguientes, que muestran que los servidores github están en mis hosts conocidos almacenados por dirección IP.

Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '192.30.255.113'
Offending key for IP in /.ssh/known_hosts:19
Matching host key in /.ssh/known_hosts:178
Are you sure you want to continue connecting (yes/no)? yes

Tendrías que buscar miles de direcciones IP asociadas con los servicios de github.com para limpiarlas… 😈

Diseñé un script de Ruby para buscar direcciones IP de github publicadas a través de la MetaAPI de GitHub. Es limitado: se salta los enormes rangos de IP de “acciones” y solo funciona para IPv4, pero con suerte ayuda a que alguien más no tenga que presionar yes un montón de veces

https://gist.github.com/jcward/5a64c17a6b61de0f7a4d85d004e7679e

Reproducido aquí con fines de archivo:

#!/usr/bin/env ruby
#
# https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints
# https://stackoverflow.com/questions/75830783
#
# Scan for github IP addresses in your knwon_hosts and remove them
# - Takes ~1.5 minutes on my machine
# - Skips the huge "actions" IP ranges
# - Skips IPv6

require 'json'

meta = JSON.parse `curl -s https://api.github.com/meta`

def num_to_ipv4 v
  (v >> 24 & 255).to_i.to_s + "." +
  (v >> 16 & 255).to_i.to_s + "." +
  (v >> 8 & 255).to_i.to_s + "." +
  (v >> 0 & 255).to_i.to_s
end

def get_ips_for octals, bits
  ips = []
  base = (octals[0] << 24) | (octals[1] << 16) | (octals[2] << 8) | octals[3]
  num = 2**(32-bits)
  0.upto(num) { |add|
    ips.push( num_to_ipv4( base + add ) )
  }
  return ips
end

meta.each { |key, value|
  next if key=="actions" # These ranges are too large
  if (value.is_a?(Array)) then
    value.each { |ip|
      if (ip.match(/(\d+)\.(\d+)\.(\d+)\.(\d+)\/(\d+)/)) then
        octals = [$1, $2, $3, $4].map(&:to_i)
        bits = $5.to_i
        ips = get_ips_for(octals, bits)
        puts "# Scanning #{ key } range -- #{ ips.length } IPs"
        ips.each { |ip|
          search = `ssh-keygen -H -F #{ ip }`
          if (search.length > 10) then
            puts "Running: ssh-keygen -R #{ ip }"
            `ssh-keygen -R #{ ip }`
          end
        }
      end
    }
  end
}

  • Esta podría ser una solución si no está usando ssh para nada más, pero si tiene otros servidores a los que se conecta, esto significa que cualquier cambio en sus claves pasará desapercibido. (Y obviamente tienes algunos otros ya que las claves están en las líneas 14 y 15 de tu known_hosts. Mejor elimine la clave como en la respuesta de @ bk2204, o anote el número de línea (14 en su caso) y elimine la línea 14 manualmente.

    -Guntram Blohm

    24 de marzo a las 21:24

  • HTTPS y SSH usan diferentes claves privadas. La clave privada HTTPS no se filtró, solo la clave privada SSH.

    – JBYoshi

    24 de marzo a las 22:01

  • @JBYoshi, veo varios votos a favor en su comentario, entonces, ¿puede explicar más sobre lo que eso significa y cómo es pertinente? No entiendo lo que me está diciendo o si está indicando que debería hacer algo diferente, pero quiero aprender más.

    – Gabriel grapas

    25 de marzo a las 19:57

  • Gabriel, JBYoshi le está respondiendo a Davislor, quien insinuó que hubo una circularidad al verificar las huellas dactilares con la llave que estás tratando de verificar. En realidad, está verificando claves SSH con huellas dactilares verificadas a través de HTTPS, que no se vieron afectadas por la filtración. Así que no hay circularidad. Todo está bien.

    -Luca Citi

    26 de marzo a las 1:54

  • Sí, respondieron mi pregunta. Ha habido infracciones en las que alguien “verificó” con una clave o suma de verificación que obtuvo de un sitio que controla el atacante.

    – Davislor

    26 de marzo a las 15:52


¿Ha sido útil esta solución?