Vous vous connectez en SSH a votre serveur et voyez ceci :

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Effrayant. Decortiquons cela.

La Menace : Stocker Maintenant, Dechiffrer Plus Tard

Le chiffrement SSH actuel est mathematiquement solide ; le casser prendrait des millions d'annees a un ordinateur classique.

Mais les ordinateurs quantiques jouent selon des regles differentes. Un ordinateur quantique suffisamment puissant executant l'algorithme de Shor peut casser les mathematiques qui protegent la plupart de la cryptographie a cle publique actuelle en quelques heures, pas en millions d'annees.

Voici la partie troublante : les ordinateurs quantiques assez puissants pour faire cela n'existent pas encore. Alors pourquoi s'inquieter maintenant ?

Parce que des adversaires, en particulier des etats-nations, enregistrent deja le trafic chiffre aujourd'hui avec l'intention de le dechiffrer plus tard, une fois le materiel quantique mature. C'est l'attaque "stocker maintenant, dechiffrer plus tard" (SNDL). Si vous envoyez quelque chose de sensible via SSH qui doit rester secret pendant les 10 a 20 prochaines annees, vous etes deja a risque.

Qu'est-ce que l'Echange de Cles ?

Avant que SSH puisse chiffrer votre session, les deux parties doivent se mettre d'accord sur un secret partage, une cle temporaire utilisee pour tout chiffrer. Cette negociation s'appelle l'echange de cles (Kex).

Classique vs Echange de Cles Post-Quantique

Post-Quantique (sur contre les ordinateurs quantiques)

AlgorithmeVersion OpenSSHNotes
sntrup761x25519-sha512@openssh.com8.5+Disponible maintenant. Hybride : NTRU Prime + X25519.
mlkem768x25519-sha2569.9+Standard de reference. Hybride : ML-KEM-768 + X25519. Normalise NIST FIPS 203.

Les deux sont des algorithmes hybrides : ils superposent un algorithme post-quantique au-dessus d'un classique. Cela signifie :

  • Si l'algo PQ a une faille -> X25519 vous protege toujours (securite classique).
  • Si un ordinateur quantique attaque -> la couche PQ vous protege toujours.

La Solution

Etape 1 : Editer /etc/ssh/sshd_config

Ajoutez l'algorithme PQ au debut de la liste. OpenSSH negocie dans l'ordre ; le premier qui correspond gagne.

Si vous etes sur OpenSSH 9.9+ (verifiez avec ssh -V) :

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Si vous etes sur OpenSSH 8.5-9.8 (comme le 9.6p1 fourni avec Ubuntu 24.04) :

KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Etape 2 : Valider et Redemarrer

Toujours valider avant de redemarrer -- une faute de frappe dans sshd_config peut vous bloquer : sudo sshd -t

Si pas d'erreurs : sudo systemctl restart sshd

TL;DR

QuestionReponse
Suis-je en train de me faire pirater maintenant ?Non. Il s'agit des futurs ordinateurs quantiques.
Dois-je agir immediatement ?Donnees sensibles a longue duree de vie : oui. Serveurs personnels : bientot.
Quel algorithme dois-je utiliser ?mlkem768x25519-sha256 (OpenSSH 9.9+) ou sntrup761x25519-sha512@openssh.com (8.5+)
Cela va-t-il casser les anciens clients ?Non, gardez les algorithmes classiques comme solutions de repli.

L'ere quantique n'est pas encore arrivee, mais la fenetre pour se preparer est maintenant. Mettre a jour KexAlgorithms prend deux minutes et c'est l'un des gains les plus faciles en matiere de durcissement des serveurs modernes.

Ubuntu 24.04 est fourni avec OpenSSH 9.6p1, qui supporte sntrup761x25519-sha512@openssh.com en standard. OpenSSH 9.9+ (disponible via PPA ou distributions plus recentes) ajoute le mlkem768x25519-sha256 normalise par le NIST.