GitHub activa el intercambio de claves SSH poscuántico, por ahora no en EE. UU.

Hoy, 14 de octubre de 2026, GitHub ha empezado a aplicar dos cambios para SSH: las nuevas claves RSA que se suban deben tener al menos 3072 bits, y en algunas conexiones se activa el algoritmo de intercambio de claves poscuántico mlkem768x25519-sha256. Los cambios afectan a las conexiones SSH; los usuarios de Git por HTTPS no tienen que cambiar su configuración a raíz de este anuncio.

El anuncio de GitHub del 22 de septiembre indica que el algoritmo estará disponible en github.com y GitHub Enterprise Cloud con residencia de datos, excepto en la región de EE. UU. Se trata del inicio de la compatibilidad por parte de la plataforma: el uso efectivo del nuevo algoritmo también depende del cliente SSH y de su configuración.

Qué cambia exactamente

Las nuevas claves RSA de SSH que se suban después del 14 de octubre deben tener al menos 3072 bits. No es necesario cambiar las claves RSA existentes solo por su longitud: GitHub recomienda usar con ellas firmas RSA-SHA-2, rsa-sha2-256 o rsa-sha2-512. En su documentación, la empresa también recomienda Ed25519 para las nuevas claves cuando este tipo sea adecuado para el entorno de trabajo.

El segundo cambio afecta a la negociación de la clave de sesión. mlkem768x25519-sha256 combina ML-KEM —un algoritmo poscuántico de encapsulación de claves— con X25519. Según el plan de GitHub, los clientes compatibles configurados para dar preferencia a este algoritmo podrán seleccionarlo automáticamente. Los clientes antiguos deberían recurrir a un algoritmo de compatibilidad admitido.

Qué debería comprobar el equipo

1. Identificar el método de conexión. Compruebe las direcciones de los remotos de Git: las que empiezan por https:// no se ven afectadas por los cambios de SSH. En el caso de SSH, revise los clientes, las bibliotecas y las integraciones utilizadas.
2. Comprobar las firmas RSA. Asegúrese de que el cliente y la biblioteca utilizada admitan RSA-SHA-2. GitHub especifica versiones mínimas para implementaciones populares, como OpenSSH 7.2p1, Go SSH 0.16.0 y libssh2 1.11.0.
3. Revisar las nuevas claves. Si la política de la organización exige RSA, la nueva clave debe tener al menos 3072 bits. Para una clave RSA ya subida, es más importante que admita el algoritmo de firma que generar un reemplazo solo por este cambio.
4. Comprobar la compatibilidad del cliente con ML-KEM. La actualización de la plataforma no garantiza por sí sola que un cliente concreto elija el nuevo intercambio de claves. Primero, revise su documentación y su comportamiento en una conexión de prueba; para los clientes antiguos, planifique la actualización según el calendario adoptado por la organización.

Hay también una fase aparte que comenzará más adelante: GitHub ha programado desactivaciones de prueba de las firmas RSA antiguas con SHA-1 y del mecanismo diffie-hellman-group-exchange-sha256 para el 4 de noviembre y el 9 de diciembre de 2026, respectivamente, y prevé su eliminación definitiva para el 13 de enero de 2027. Por eso, el requisito que entra en vigor hoy para la longitud de las nuevas claves RSA y la futura retirada de algoritmos antiguos deben tratarse como tareas de migración distintas.

Para los equipos, la prioridad práctica de hoy es inventariar los clientes SSH y comprobar RSA-SHA-2; después, probar por separado la compatibilidad con ML-KEM. Por ahora, no se ha anunciado la disponibilidad del nuevo algoritmo para los usuarios de EE. UU.; el requisito de tamaño para las nuevas claves RSA ya se aplica a las que se suban después del 14 de octubre.