Sécuriser SSH avec des algorithmes post-quantiques

Sécuriser SSH avec des algorithmes post-quantiques

·5 min de lecture·Mis à jour le 13 janvier 2026

Pourquoi le post-quantique maintenant

L'objection habituelle — « les ordinateurs quantiques, c'est loin » — ignore une menace bien concrète et actuelle : le harvest now, decrypt later. Un attaquant capture le trafic chiffré aujourd'hui, le stocke, et attend vingt ans que la technologie quantique permette de le déchiffrer rétroactivement.

Pour un NAS perso, le risque reste limité. Mais OpenSSH supporte les algos post-quantiques depuis la 9.x et Debian 13 embarque une version assez fraîche : autant prendre les bonnes habitudes.

Les clés hôte

Par défaut, Debian génère ECDSA, Ed25519 et RSA. On supprime ECDSA et DSA (obsolètes) pour ne garder qu'Ed25519 et RSA 4096 :

# Supprimer les clés hôte non souhaitées
rm -f /etc/ssh/ssh_host_ecdsa_key*
rm -f /etc/ssh/ssh_host_dsa_key*

# Régénérer la clé RSA en 4096 bits si nécessaire
ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

Puis on est explicite dans sshd_config :

# /etc/ssh/sshd_config - Clés hôte
 HostKey /etc/ssh/ssh_host_ed25519_key
 HostKey /etc/ssh/ssh_host_rsa_key
 HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

Ed25519 en priorité — compact, rapide, basé sur Curve25519 — et RSA 4096 en backup pour les clients pas à jour.

Échanges de clés post-quantiques

OpenSSH propose des algos hybrides combinant un échange classique (X25519) avec un algo post-quantique. Si l'algo post-quantique se révèle faible, la sécurité classique reste intacte — et inversement.

# /etc/ssh/sshd_config - Échange de clés
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,diffie-hellman-group16-sha512
  • mlkem768x25519-sha256 : hybride ML-KEM 768 (standard NIST FIPS 203, ex-CRYSTALS-Kyber) + X25519. L'option la plus récente et la recommandation actuelle.
  • sntrup761x25519-sha512@openssh.com : hybride NTRU Prime 761 + X25519, présent depuis plus longtemps dans OpenSSH, excellent fallback.
  • curve25519-sha256 : échange classique, pour les clients sans support post-quantique.
  • diffie-hellman-group16-sha512 : DH classique en dernier recours.

Chiffrement et MACs

# /etc/ssh/sshd_config - Chiffrement
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

ChaCha20-Poly1305 par défaut, performant et bien étudié ; les AES-GCM pour les machines avec accélération AES-NI, dont l'Intel N95.

Authentification durcie

Clés SSH uniquement, pas de mots de passe :

# /etc/ssh/sshd_config - Authentification
 PermitRootLogin no
 PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

PermitRootLogin no impose de passer par nasadmin puis sudo, MaxAuthTries 3 limite le brute-force, et LoginGraceTime 30 réduit la fenêtre d'authentification à trente secondes, ce qui décourage rapidement les bots.

Bannière d'avertissement

Souvent ignorée, elle est pourtant obligatoire dans certaines juridictions pour pouvoir poursuivre une tentative d'intrusion :

# /etc/ssh/sshd_config
Banner /etc/ssh/banner.txt

# /etc/ssh/banner.txt
*************************************************************
WARNING: Unauthorized access to this system is prohibited.
All connections are monitored and recorded.
By connecting, you agree to comply with applicable policies.
*************************************************************

Automatisation avec Ansible

Le tout est déployé via un rôle Ansible s'appuyant sur la collection devsec.hardening, qui applique des centaines de règles basées sur CIS et ANSSI :

# playbook.yml - extrait
- name: Harden SSH
  hosts: nas
  roles:
    - role: devsec.hardening.ssh_hardening
      vars:
        ssh_kex:
          - mlkem768x25519-sha256
          - sntrup761x25519-sha512@openssh.com
          - curve25519-sha256
          - diffie-hellman-group16-sha512
        ssh_host_key_algorithms:
          - ssh-ed25519
          - rsa-sha2-512
          - rsa-sha2-256
        ssh_ciphers:
          - chacha20-poly1305@openssh.com
          - aes256-gcm@openssh.com
          - aes128-gcm@openssh.com
        ssh_allow_users: nasadmin
        ssh_max_auth_retries: 3

Le playbook est idempotent : le relancer cinquante fois ne change rien.

Côté client et vérification

Une clé Ed25519 côté client, et un contrôle des algos supportés :

# Générer une clé Ed25519
ssh-keygen -t ed25519 -C "user@workstation"

# Vérifier les algos supportés
ssh -Q kex

Si mlkem768x25519-sha256 apparaît dans la sortie, le client est compatible. Après déploiement, on valide la négociation réelle :

ssh -vv nasadmin@192.168.1.50 2>&1 | grep "kex:"

# Résultat attendu :
# debug1: kex: algorithm: mlkem768x25519-sha256

Configurer SSH en post-quantique n'est ni complexe ni coûteux en performance : avec OpenSSH 9.x et Debian 13, tout est disponible, il suffit de poser les bons paramètres et de laisser Ansible faire le reste.

PartagerLinkedInXBluesky

Articles similaires