Sécuriser SSH avec des algorithmes post-quantiques

Pourquoi le post-quantique maintenant ?

L'argument classique, c'est "oh, les ordi quantiques c'est loin encore". Peut-être. Mais il existe une menace bien concrète qui se passe maintenant : le harvest now, decrypt later. En gros, un attaquant capture votre trafic chiffré aujourd'hui, le balance dans un disque dur, et attendra 20 ans que la technologie quantique arrive pour le déchiffrer rétroactivement.

Pour un NAS perso ? Le risque est limité. Mais si vous construisez une infrastructure, autant prendre les bonnes habitudes dès le départ. OpenSSH support les algos post-quantiques depuis la 9.x, et Debian 13 a une version assez fraîche pour en profiter.

Les clés hôte : faire le ménage

Première étape : se débarrasser des clés pourries. Par défaut, Debian génère ECDSA, Ed25519, et RSA. On va supprimer ECDSA et DSA (obsolète), et garder juste Ed25519 et RSA 4096 bits :

# 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 ""

Après, dans sshd_config, on est explicite :

# /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é : c'est compact, rapide, et basé sur Curve25519 qui est moderne. RSA 4096 en backup pour les vieux clients qui sont pas à jour.

Échanges de clés post-quantiques

Là ça devient marrant. OpenSSH propose maintenant des algos hybrides qui combinent un échange classique (X25519) avec un algo post-quantique. Si l'algo post-quantique se révèle pourri, la sécurité classique reste intacte. Et vice-versa. C'est du hedging de sécurité.

# /etc/ssh/sshd_config - Échange de clés
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,diffie-hellman-group16-sha512

Décomposons ce truc :

• mlkem768x25519-sha256 : hybride ML-KEM 768 (le standard NIST FIPS 203, qui s'appelait CRYSTALS-Kyber avant) + X25519. C'est l'option la plus récente, celle qu'ils recommandent.
• sntrup761x25519-sha512@openssh.com : hybride NTRU Prime 761 + X25519. C'est dans OpenSSH depuis plus longtemps, c'est un excellent fallback.
• curve25519-sha256 : échange classique, pour les clients qui comprenez pas le post-quantique encore.
• diffie-hellman-group16-sha512 : DH classique en dernier recours.

Chiffrement et MACs

Pour le chiffrement symétrique et les codes d'authentification, on reste sur des trucs qui ont fait leurs preuves :

# /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 - c'est performant et bien étudié. Les AES-GCM sont là pour les machines avec accélération AES-NI (l'Intel N95 en a). Bon choix technique.

Authentification durcie

Les mots de passe ? Non. Clés SSH uniquement :

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

Points clés :

• PermitRootLogin no : on se connecte avec nasadmin, puis sudo si besoin
• MaxAuthTries 3 : limite les tentatives de brute-force (après 3 erreurs, boff)
• LoginGraceTime 30 : 30 secondes pour s'authentifier, pas plus. Les bots se désintéressent vite.

Bannière d'avertissement

Un détail souvent ignoré mais utile. Juridiquement, dans certaines juridictions, cette bannière c'est obligatoire pour poursuivre quelqu'un qui try de s'introduire :

# /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.
*************************************************************

Ce n'est pas juste cosmétique. Franchement utile si vous travaillez dans un environnement où la compliance c'est pris au sérieux.

Automatisation avec Ansible

Tout ça ? C'est déployé via un rôle Ansible, avec la collection devsec.hardening. Cette collection applique des centaines de règles basées sur CIS et ANSSI.

Le playbook ressemble à ça :

# 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

Avantage d'Ansible : c'est idempotent. Relancer le playbook 50 fois, ça change rien. C'est exactement ce qu'on veut.

Côté client : ta clé

Pour se connecter au NAS, évidemment il faut une clé Ed25519 :

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

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

La commande ssh -Q kex vous montre ce que votre client supporte. Si mlkem768x25519-sha256 apparaît, c'est bon.

Vérification

Après le déploiement, on valide :

# Voir les algos négociés lors d'une connexion
ssh -vv nasadmin@192.168.1.50 2>&1 | grep "kex:"

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

Et voilà.

Configurer SSH avec du post-quantique, c'est pas complexe. C'est pas coûteux en performance. C'est une mesure proactive qui te protège aujourd'hui contre les menaces de demain. Avec OpenSSH 9.x et Debian 13, tout est là - faut juste configurer les bons paramètres et laisser Ansible faire le job.