Por qué GitHub de pronto rechazó una clave SSH: el archivo .pub desaparecido

• git pull de GitHub empezó a fallar de pronto en una laptop sin cambios, pero volvió a autenticarse al generar el archivo .pub correspondiente a la clave privada
• Si existe el archivo .pub, OpenSSH primero presenta la clave pública para obtener aprobación y luego firma; si no existe, envía de inmediato una solicitud de autenticación firmada
• Ambos flujos cumplen con RFC 4252 y un sshd común también los permite, pero en ese momento el frontend SSH de GitHub parecía no aceptar solicitudes firmadas directamente
• En 12 pruebas controladas, las 6 sin archivo .pub fueron rechazadas, y las 6 con el archivo tuvieron éxito
• Por el cambio en el banner del servidor se puede inferir una posible modificación del software del lado del servidor, pero como no se confirmó la causa exacta, lo más seguro es mantener también el archivo de clave pública correspondiente

---

Falla de autenticación repentina y solución

• En la laptop principal, git pull se interrumpió con el error Permission denied (publickey)
  • La clave seguía registrada en GitHub
  • En otra laptop que usaba otra clave, se podía traer el mismo repositorio sin problemas
• No se encontraron anomalías en la clave ni en la configuración del cliente
  • openssl rsa -check devolvía RSA key ok
  • Se estaba usando el algoritmo de firma más reciente, rsa-sha2-512
  • No había problemas en ~/.ssh/config y la página de estado de GitHub estaba normal
• Tras la reinstalación, el archivo de clave pública correspondiente a ~/.ssh/github_rsa había desaparecido; al generarlo con el siguiente comando, la autenticación tuvo éxito

ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub

• En pruebas controladas, las 6 ejecuciones sin archivo .pub fallaron todas, y las 6 con el archivo tuvieron éxito

El flujo de autenticación cambia según el archivo .pub

• OpenSSH usa distintos flujos de autenticación con clave pública según exista o no el archivo .pub
  • Si el archivo existe, primero presenta la clave pública y espera la aprobación del servidor antes de firmar
  • Si solo existe la clave privada, omite la verificación previa y envía directamente una solicitud de autenticación completamente firmada
• RFC 4252 permite ambos métodos, y un sshd común acepta los dos
• En ese momento, GitHub rechazaba las solicitudes de clave pública firmadas directamente, pero no se confirmó si hubo un cambio real del lado de GitHub
  • El banner del servidor en los logs de depuración aparecía como 6a2c000, no con el formato anterior babeld-<hash>
  • La posibilidad de que un nuevo software de servidor rechazara las solicitudes firmadas directamente queda solo como una hipótesis
• Para evitar el mismo problema, conviene mantener junto a la clave privada el archivo .pub correspondiente

[GN⁺]

Comentarios en Lobste.rs

• Estoy teniendo el mismo problema desde hace 4 horas, y ya está registrado en https://www.githubstatus.com/incidents/g40zcbvchny4

• Hace unas semanas cambié mi clave SSH y no borré el archivo .pub anterior, que Git estaba ignorando; aun conectándome con la clave nueva, seguía fallando.
  Recién después de activar varias opciones de depuración descubrí que el cliente SSH estaba enviando la huella anterior; ni siquiera sabía que OpenSSH leía archivos .pub, y siempre los había considerado archivos totalmente innecesarios.

• Hoy nuestro servidor de CI sufrió una falla idéntica: de pronto parecía no poder conectarse a github.com.
  Al cambiar la clave por la clave ed25519 correcta volvió a funcionar, pero esa clave tampoco tiene su archivo .pub correspondiente, así que no sé por qué se resolvió.

  • Como la clave dejó de funcionar de golpe, primero me preocupé por una posible intrusión, pero me alegra que ahora parezca que GitHub lo está atendiendo directamente.

• Hoy tuve el mismo problema y, que yo sepa, GitHub no había anunciado que planeara un cambio en el comportamiento de autenticación por SSH.

  • No parece que haya sido un cambio planificado.

• Perdí tanto la contraseña como la clave de recuperación, así que pasé por el proceso de recuperación de cuenta basada en claves SSH, pero GitHub marcó esa clave SSH como vencida y perdí por completo el acceso a la cuenta.

• Creo que en 7 u 8 años nunca he tenido un archivo .pub, así que espero que el problema se resuelva antes de la próxima vez que use GitHub.

  • El archivo de clave pública se puede regenerar fácilmente, y el comando también aparece en el artículo original.

• Si ambos flujos de autenticación son legítimos, me pregunto por qué existe el flujo de descubrimiento de claves.
  Parece que solo provoca comportamientos extraños como este y, si de todos modos se puede crear la clave pública a partir de la privada, SSH podría encargarse automáticamente.

  • Es una función para situaciones en las que la clave privada está cifrada o almacenada en un token de seguridad de hardware y no se puede usar de inmediato.
    SSH primero verifica con el servidor qué clave funcionaría, para evitar que el usuario tenga que descifrar innecesariamente una clave que con seguridad fallará en la autenticación.
    Este comportamiento también tiene efectos secundarios peculiares como https://github.com/FiloSottile/whoami.filippo.io, por lo que conviene permitir un esquema en el que el servidor tenga que conocer de antemano la clave pública del cliente para poder intentar la autenticación, en caso de que el usuario se conecte por error al servidor equivocado.

• Mi cuenta de Office 365 del trabajo también dejó de funcionar de repente hoy por primera vez en 5 años.
  Me pregunto si hubo una intrusión en Microsoft y volvieron a aplicar salting a todos los valores, o si es algo que solo les pasa a usuarios europeos por la reciente votación de Chat Control 1.0.

  • El servicio de terminación de conexiones de GitHub y la autenticación de cuentas de M365 no tienen absolutamente nada que ver; estoy 99.999% seguro de que es una coincidencia.
    Soy una de las dos personas que conozco que han trabajado tanto en Git Systems de GitHub como en la suite Office/M365 de Microsoft, así que tengo suficiente base para afirmarlo.
    Incluso si la causa fuera una política o un cambio técnico aplicado por igual a ambos servicios, son sistemas aislados entre sí, por lo que es extremadamente improbable que se desplegara el mismo día.