01 · Contexto

Qué está ocurriendo

GitHub anunció el 22 de septiembre la retirada del tipo de firma ssh-rsa que usa SHA-1, incluidos certificados basados en esa firma, y del intercambio diffie-hellman-group-exchange-sha256. La medida no elimina todas las claves RSA: una clave existente puede seguir operando si el cliente negocia rsa-sha2-256 o rsa-sha2-512.

Desde el 14 de octubre, las nuevas claves RSA cargadas para firma o autenticación deberán tener al menos 3072 bits. GitHub recomienda Ed25519 para claves nuevas cuando la compatibilidad lo permita y documenta versiones mínimas de clientes comunes con soporte robusto de RSA-SHA2.

Ese mismo día se habilitará mlkem768x25519-sha256 en github.com y en GitHub Enterprise Cloud con Data Residency, salvo la región de Estados Unidos. Los clientes compatibles lo negociarán automáticamente; los antiguos deberían usar un algoritmo alternativo admitido.

GitHub programó interrupciones de prueba para los algoritmos retirados el 4 de noviembre y el 9 de diciembre. Los remotos HTTPS no están afectados, pero sí clientes Git sobre SSH, bibliotecas embebidas, appliances, imágenes antiguas y automatizaciones que ocultan su implementación SSH.

02 · Impacto

Por qué importa

La mayoría de los equipos modernos no requerirá cambios, pero un único runner heredado puede detener builds, despliegues o recuperación de infraestructura. La transición también expone un riesgo de inventario: conocer el tipo de clave no basta, porque la firma negociada depende del cliente. Probar el flujo completo ofrece más certeza que inspeccionar archivos de claves de forma aislada.

03 · Recomendaciones

Qué conviene hacer

  • Buscar remotos git@, claves RSA, certificados SSH y usos de JSch, libssh2, PuTTY, Go SSH, TeamCity y OpenSSH en estaciones, runners, imágenes, bots y appliances.
  • Actualizar clientes a versiones que negocien RSA-SHA2 y un intercambio fuerte; generar Ed25519 para nuevos accesos cuando sea compatible o RSA de al menos 3072 bits cuando sea imprescindible.
  • Ejecutar clones, fetch, submódulos, firmas, despliegues y recuperación de secretos en una matriz representativa antes de cada brownout; alertar fallas de negociación por cliente y propietario.
  • Mantener inventario de huellas y dueños, retirar claves sin uso y documentar la ruta HTTPS de contingencia sin debilitar la verificación de host ni aceptar algoritmos obsoletos globalmente.
Fuente principalGitHub ChangelogConsultar publicación original