Michael JohnsonAujourd’hui, 14 octobre 2026, GitHub a commencé à appliquer deux changements concernant SSH : les nouvelles clés RSA téléversées doivent mesurer au moins 3 072 bits, et l’algorithme postquantique d’échange de clés mlkem768x25519-sha256 est activé pour une partie des connexions. Ces changements concernent les connexions SSH ; les utilisateurs de Git via HTTPS n’ont pas besoin de modifier leur configuration à la suite de cette annonce.
Selon l’annonce de GitHub du 22 septembre, l’algorithme sera disponible sur github.com et GitHub Enterprise Cloud avec Data Residency, à l’exception de la région des États-Unis. Il s’agit du début de la prise en charge par la plateforme : l’utilisation effective du nouvel algorithme dépend aussi du client SSH et de sa configuration.
Ce qui change exactement
Les nouvelles clés RSA SSH téléversées après le 14 octobre doivent mesurer au moins 3 072 bits. Il n’est pas nécessaire de remplacer les clés RSA existantes uniquement en raison de leur longueur : GitHub recommande d’utiliser avec celles-ci les signatures RSA-SHA-2, rsa-sha2-256 ou rsa-sha2-512. Dans sa documentation, l’entreprise recommande également Ed25519 pour les nouvelles clés, lorsque ce type convient à l’environnement de travail.
Le second changement concerne la négociation de la clé de session. mlkem768x25519-sha256 associe ML-KEM, un algorithme postquantique d’encapsulation de clés, à X25519. Selon le plan de GitHub, les clients compatibles configurés pour privilégier cet algorithme pourront le sélectionner automatiquement. Les anciens clients devraient basculer vers un algorithme de compatibilité pris en charge.
Points à vérifier au sein de l’équipe
- Déterminer le mode de connexion. Vérifiez les adresses des dépôts Git distants : les entrées commençant par
https://ne sont pas concernées par les changements SSH. Pour SSH, vérifiez les clients, bibliothèques et intégrations utilisés. - Vérifier les signatures RSA. Assurez-vous que le client et la bibliothèque utilisée prennent en charge RSA-SHA-2. GitHub indique les versions minimales de plusieurs implémentations populaires, notamment OpenSSH 7.2p1, Go SSH 0.16.0 et libssh2 1.11.0.
- Vérifier les nouvelles clés. Si la politique de l’organisation impose RSA, la nouvelle clé doit mesurer au moins 3 072 bits. Pour une clé RSA déjà téléversée, la prise en charge de l’algorithme de signature compte davantage que la génération d’une clé de remplacement uniquement pour répondre à ce changement.
- Vérifier la prise en charge de ML-KEM par le client. Une mise à jour de la plateforme ne garantit pas, à elle seule, que le client concerné choisira le nouvel échange de clés. Commencez par consulter sa documentation et tester son comportement lors d’une connexion d’essai ; pour les anciens clients, prévoyez une mise à niveau selon le calendrier adopté par l’organisation.
Une étape distincte interviendra plus tard : GitHub a prévu des désactivations d’essai de l’ancienne signature RSA avec SHA-1 et du mécanisme diffie-hellman-group-exchange-sha256 les 4 novembre et 9 décembre 2026, avant leur suppression définitive prévue le 13 janvier 2027. Il faut donc considérer l’exigence actuelle concernant la longueur des nouvelles clés RSA et l’abandon futur des anciens algorithmes comme deux tâches de migration distinctes.
Pour les équipes, la priorité immédiate consiste à inventorier les clients SSH et à vérifier la prise en charge de RSA-SHA-2, puis à tester séparément la compatibilité avec ML-KEM. La disponibilité du nouvel algorithme n’a pas encore été annoncée pour les utilisateurs aux États-Unis ; l’exigence de taille minimale des nouvelles clés RSA s’applique néanmoins déjà aux téléversements effectués après le 14 octobre.