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?
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 yes
asegúrese de que la nueva clave que se muestra sea válida, utilizando la lista:
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 degithub.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
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
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-keygen
por 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
grapas gabriel
En Ubuntu 20.04, usando una clave ed25519 en Github, incluso después de ejecutar ssh-keygen -R github.com
segú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 yes
Como 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 yes
sin 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
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
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