OpenSSH

Selon Forescout (billet de blog référencé), l’adoption de la cryptographie post-quantique (PQC) progresse côté serveurs SSH mais reste en net retrait sur les appareils non gérés, alors que les échéances de migration se situent entre 2030 et 2035. Principaux constats chiffrés 🔍 Support PQC sur serveurs SSH: 8,5% (26% pour OpenSSH) Adoption par type d’actifs: IT 42% vs IoT 20% vs OT/équipements réseau 11% vs IoMT 2% Secteurs les plus en retard: industries dépendantes d’actifs non gérés (manufacturing, oil & gas, mining) Urgences mises en avant: inventorier les actifs, classifier les données (longévité/sensibilité), établir des feuilles de route de migration Équipements critiques vulnérables: routeurs et appliances VPN, cibles privilégiées pour l’accès privilégié Détails techniques (SSH/TLS) 🔐 ...

Source : openssh.com. Le projet OpenSSH détaille l’adoption des algorithmes d’échange de clés post‑quantiques pour SSH, le changement de défaut vers mlkem768x25519-sha256, et l’introduction en 10.1 d’un avertissement lorsque la connexion n’emploie pas de schéma post‑quantique. Depuis OpenSSH 9.0 (avril 2022), un échange de clés post‑quantique est proposé par défaut via sntrup761x25519-sha512. En OpenSSH 9.9, mlkem768x25519-sha256 a été ajouté et est devenu le schéma par défaut en 10.0 (avril 2025). En OpenSSH 10.1, un avertissement informe l’utilisateur si un KEX non post‑quantique est sélectionné, signalant un risque d’attaque « store now, decrypt later ». Cet avertissement est activé par défaut et peut être désactivé via l’option WarnWeakCrypto dans ssh_config(5). Contexte et menace : des ordinateurs quantiques suffisamment puissants pourraient casser certains schémas cryptographiques classiques. Même s’ils n’existent pas encore, les sessions SSH peuvent être collectées aujourd’hui et déchiffrées plus tard (attaque « store now, decrypt later »), d’où la nécessité d’algorithmes post‑quantiques pour l’accord de clés. ...