Comment securiser vos cles SSH et migrer vers l'authentification post-quantique en 7 etapes

Vos cles SSH sont probablement le maillon le plus faible de votre chaine de securite. La plupart des developpeurs generent une paire de cles RSA lors de leur premier jour et ne la changent plus jamais. Pas de rotation, pas de passphrase, pas de durcissement du client, et certainement pas de reflexion sur la cryptographie post-quantique. En 2026, apres les vulnerabilites critiques corrigees dans OpenSSH 10.4 et les avancees rapides des ordinateurs quantiques, il est temps de prendre au serieux la securite de vos cles SSH. Ce guide vous donne 7 etapes concretes, de l'audit de vos cles existantes jusqu'a la preparation post-quantique, avec des commandes et des configurations que vous pouvez appliquer des aujourd'hui.

Etape 1 : Auditer vos cles SSH existantes

Avant de generer de nouvelles cles, vous devez savoir ce que vous avez. La premiere etape est un inventaire complet de toutes les cles SSH presentes sur votre machine et sur vos serveurs. Beaucoup de developpeurs accumulent des cles au fil des annees sans jamais supprimer les anciennes.

Listez toutes les cles de votre repertoire SSH et examinez leur type, leur taille et leur age :

# Lister toutes les cles avec leur type et taille
for key in ~/.ssh/id_*; do
  [ -f "$key" ] && ssh-keygen -l -f "$key"
done

# Resultat typique :
# 2048 SHA256:abc123... user@machine (RSA)     <-- OBSOLETE
# 1024 SHA256:def456... user@old-pc (DSA)      <-- DANGEREUX
# 256  SHA256:ghi789... user@laptop (ED25519)   <-- OK

# Trouver les cles RSA < 3072 bits (a migrer)
for key in ~/.ssh/id_rsa*; do
  [ -f "$key" ] && bits=$(ssh-keygen -l -f "$key" | awk '{print $1}')
  [ "$bits" -lt 3072 ] 2>/dev/null && echo "MIGRER: $key ($bits bits)"
done

Verifiez egalement les cles autorisees sur vos serveurs. Le fichier ~/.ssh/authorized_keys contient souvent des cles d'anciens collaborateurs, des cles de deploiement oubliees ou des cles sans commentaire identifiant. Auditez chaque entree :

# Sur chaque serveur : auditer les cles autorisees
while IFS= read -r line; do
  echo "$line" | ssh-keygen -l -f - 2>/dev/null || echo "CLE INVALIDE: $line"
done < ~/.ssh/authorized_keys

# Chercher les cles DSA (desactivees par defaut depuis OpenSSH 7.0)
grep -n "ssh-dss" ~/.ssh/authorized_keys && echo "ALERTE: cles DSA detectees"

# Chercher les cles RSA courtes
grep -n "ssh-rsa" ~/.ssh/authorized_keys

Supprimez immediatement toutes les cles DSA (ssh-dss) et les cles RSA de moins de 2048 bits. Documentez chaque cle restante avec un commentaire identifiant le proprietaire, la date de creation et l'usage prevu. Si une cle n'a pas de commentaire et que personne ne peut l'identifier, supprimez-la : une cle orpheline est une porte d'entree potentielle.

Etape 2 : Generer des cles Ed25519 modernes

Ed25519 est le standard recommande pour les cles SSH en 2026. Base sur la courbe elliptique Curve25519, il offre une securite equivalente a RSA 3072 bits avec des cles de seulement 256 bits. Les signatures sont plus rapides, les cles sont plus courtes et l'algorithme est resistant aux attaques par canal auxiliaire par conception.

# Generer une cle Ed25519 avec passphrase et commentaire
ssh-keygen -t ed25519 -C "prenom.nom@entreprise.com-2026-07" -a 100

# -t ed25519     : algorithme Ed25519
# -C "..."       : commentaire identifiant (email + date)
# -a 100         : 100 rounds de derivation KDF (protection passphrase)

# Resultat :
# ~/.ssh/id_ed25519       (cle privee)
# ~/.ssh/id_ed25519.pub   (cle publique)

# Verifier la cle generee
ssh-keygen -l -f ~/.ssh/id_ed25519.pub
# 256 SHA256:xyz... prenom.nom@entreprise.com-2026-07 (ED25519)

Le parametre -a 100 est crucial. Il definit le nombre de rounds de derivation de la passphrase. Par defaut, OpenSSH utilise 16 rounds, ce qui est insuffisant pour resister a une attaque par force brute sur la passphrase si votre cle privee est volee. Avec 100 rounds, le deverrouillage prend environ 1 seconde (imperceptible pour l'utilisateur) mais rend le brute-force significativement plus couteux.

Si vous avez plusieurs machines, generez une cle distincte par machine plutot qu'une cle unique copiee partout. En cas de compromission d'une machine, vous ne revoquez qu'une seule cle sans affecter les autres. Nommez vos cles de maniere explicite :

# Cle dediee par machine et par usage
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_github -C "github-laptop-pro-2026-07"
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_production -C "prod-servers-2026-07"
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_staging -C "staging-servers-2026-07"

Etape 3 : Configurer le durcissement de votre client SSH

La generation d'une bonne cle ne suffit pas si votre client SSH accepte des algorithmes faibles ou des configurations dangereuses. Le fichier ~/.ssh/config est votre premiere ligne de defense. Voici une configuration durcie qui desactive les algorithmes obsoletes et force les bonnes pratiques :

# ~/.ssh/config - Configuration durcie (juillet 2026)

Host *
    # Algorithmes de cle : Ed25519 uniquement, fallback ECDSA si necessaire
    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp384
    PubkeyAcceptedAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp384

    # Echange de cles : Curve25519 uniquement
    KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

    # Chiffrement : AES-256-GCM et ChaCha20
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr

    # MAC : HMAC-SHA2 en mode ETM uniquement
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

    # Desactiver le forwarding d agent par defaut
    ForwardAgent no

    # Verification stricte de la cle hote
    StrictHostKeyChecking ask
    UpdateHostKeys yes

    # Timeout et keepalive
    ConnectTimeout 10
    ServerAliveInterval 60
    ServerAliveCountMax 3

    # Desactiver les protocoles inutiles
    AddKeysToAgent yes
    IdentitiesOnly yes

# Configuration specifique par hote
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github
    IdentitiesOnly yes

Host production-*
    IdentityFile ~/.ssh/id_ed25519_production
    ForwardAgent no
    IdentitiesOnly yes

Les points critiques de cette configuration : IdentitiesOnly yes empeche le client d'envoyer toutes vos cles au serveur (ce qui revele leur existence). ForwardAgent no desactive le forwarding d'agent SSH par defaut, ce qui empeche un serveur compromis d'utiliser vos cles pour se connecter a d'autres serveurs. UpdateHostKeys yes permet la migration progressive des cles hote vers des algorithmes plus forts. L'algorithme d'echange de cles sntrup761x25519-sha512 est deja un hybride classique/post-quantique disponible dans OpenSSH depuis la version 9.0.

Etape 4 : Activer l'authentification multi-facteur pour SSH

Une cle SSH, meme Ed25519 avec passphrase, reste un facteur unique : « quelque chose que vous avez » (le fichier de cle). L'authentification FIDO2/U2F ajoute un second facteur physique : vous devez toucher votre cle de securite materielle pour chaque connexion. Meme si un attaquant vole votre cle privee et votre passphrase, il ne pourra pas se connecter sans la cle physique.

# Generer une cle liee a une cle de securite FIDO2 (YubiKey, SoloKey, Nitrokey)
ssh-keygen -t ed25519-sk -C "fido2-yubikey-2026-07"

# Options avancees :
# -O resident : stocke la cle sur le dispositif (portable entre machines)
# -O verify-required : exige un PIN en plus du toucher physique
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "fido2-resident-2026-07"

# Lister les cles residentes sur votre cle de securite
ssh-keygen -K

# Resultat : la cle privee est un handle, pas la cle reelle
# La signature ne peut etre generee que par le dispositif FIDO2 physique

Le mode resident est particulierement interessant pour les developpeurs qui travaillent sur plusieurs machines. La cle privee est stockee directement sur le dispositif FIDO2, ce qui signifie que vous pouvez la telecharger sur n'importe quelle machine avec ssh-keygen -K sans copier de fichiers. L'option verify-required ajoute une verification de PIN en plus du toucher physique, transformant l'authentification en trois facteurs : la cle physique (ce que vous avez), le PIN (ce que vous savez) et le toucher (preuve de presence).

Cote serveur, aucune configuration speciale n'est necessaire : les cles ed25519-sk sont acceptees comme des cles Ed25519 classiques dans authorized_keys. La seule exigence est OpenSSH 8.2 ou superieur cote serveur, ce qui est le cas de toutes les distributions Linux actuelles.

Etape 5 : Tester la cryptographie post-quantique avec OpenSSH 10.4

OpenSSH 10.4, publie en juillet 2026, introduit le support experimental des signatures hybrides ML-DSA-44 + Ed25519. ML-DSA (Module-Lattice Digital Signature Algorithm, le nom standardise par le NIST de CRYSTALS-Dilithium) est le premier algorithme de signature post-quantique approuve par le NIST (FIPS 204). L'approche hybride signifie que la signature combine un algorithme classique (Ed25519) et un algorithme post-quantique (ML-DSA-44) : les deux doivent etre valides pour que la connexion soit autorisee. Pour plus de details sur les correctifs de securite d'OpenSSH 10.4, consultez notre article compagnon sur les vulnerabilites corrigees.

# Verifier votre version d'OpenSSH
ssh -V
# OpenSSH_10.4p1, OpenSSL 3.4.1 14 Jul 2026

# Generer une paire de cles hybride ML-DSA + Ed25519
# ATTENTION : experimental, ne pas deployer en production
ssh-keygen -t mlkem25519 -C "post-quantique-test-2026-07"

# La cle publique est plus grande (environ 1.3 Ko vs 68 octets pour Ed25519)
wc -c ~/.ssh/id_mlkem25519.pub
# 1312 bytes

# Tester la connexion vers un serveur OpenSSH 10.4
ssh -o HostKeyAlgorithms=mlkem25519 -v test-server.local 2>&1 | grep "kex:"
# debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
# debug1: kex: host key algorithm: mlkem25519

Important : ne deployez pas les cles ML-DSA en production en juillet 2026. Le support est marque experimental par OpenSSH. Les raisons : les performances de verification sont plus lentes (environ 3x par rapport a Ed25519), les cles publiques sont 20x plus grandes, et le standard FIPS 204 n'a pas encore ete pleinement audite par la communaute open source. L'objectif aujourd'hui est de tester, de vous familiariser avec les commandes et de preparer votre infrastructure pour la migration future.

# Environnement de test isole avec Docker
docker run -it --name ssh-pq-test ubuntu:24.04 bash

# Dans le conteneur : installer OpenSSH 10.4
apt update && apt install -y openssh-server openssh-client
# Configurer sshd pour accepter les cles hybrides
echo "PubkeyAcceptedAlgorithms +mlkem25519" >> /etc/ssh/sshd_config
echo "HostKeyAlgorithms +mlkem25519" >> /etc/ssh/sshd_config
# Generer les cles hote hybrides
ssh-keygen -t mlkem25519 -f /etc/ssh/ssh_host_mlkem25519_key -N ""
service ssh start

# Depuis votre machine : tester la connexion
ssh -o HostKeyAlgorithms=mlkem25519 -p 2222 root@localhost

Notez que l'echange de cles post-quantique (sntrup761x25519-sha512) est en revanche disponible et stable depuis OpenSSH 9.0. Il protege la confidentialite de la session contre un attaquant qui enregistrerait le trafic chiffre aujourd'hui pour le dechiffrer plus tard avec un ordinateur quantique (attaque « harvest now, decrypt later »). Vous pouvez l'activer des maintenant en production dans votre ~/.ssh/config en le placant en premiere position des KexAlgorithms (c'est ce que nous avons fait a l'etape 3).

Etape 6 : Automatiser la rotation des cles SSH

Une cle SSH qui ne change jamais est une cle qui finira par etre compromise. La rotation reguliere des cles limite la fenetre d'exposition en cas de vol. L'objectif : une rotation automatisee tous les 90 jours pour les cles de deploiement et tous les 6 mois pour les cles personnelles des developpeurs.

#!/bin/bash
# rotate-ssh-keys.sh - Script de rotation automatique
# A executer via cron : 0 9 1 */3 * /usr/local/bin/rotate-ssh-keys.sh

KEY_DIR="$HOME/.ssh"
KEY_NAME="id_ed25519_production"
BACKUP_DIR="$KEY_DIR/archive"
DATE=$(date +%Y-%m-%d)
SERVERS="server1.example.com server2.example.com server3.example.com"

# Creer le repertoire d'archive
mkdir -p "$BACKUP_DIR"

# Sauvegarder l'ancienne cle
if [ -f "$KEY_DIR/$KEY_NAME" ]; then
  mv "$KEY_DIR/$KEY_NAME" "$BACKUP_DIR/${KEY_NAME}_${DATE}.bak"
  mv "$KEY_DIR/${KEY_NAME}.pub" "$BACKUP_DIR/${KEY_NAME}_${DATE}.pub.bak"
fi

# Generer la nouvelle cle
ssh-keygen -t ed25519 -f "$KEY_DIR/$KEY_NAME" -C "production-$DATE" -a 100 -N ""

# Deployer la nouvelle cle sur tous les serveurs
for server in $SERVERS; do
  ssh-copy-id -i "$KEY_DIR/${KEY_NAME}.pub" "$server" 2>/dev/null
  if [ $? -eq 0 ]; then
    echo "[OK] Cle deployee sur $server"
    # Supprimer l'ancienne cle du serveur
    OLD_KEY=$(cat "$BACKUP_DIR/${KEY_NAME}_${DATE}.pub.bak" | awk '{print $2}')
    ssh "$server" "sed -i '/$OLD_KEY/d' ~/.ssh/authorized_keys"
  else
    echo "[ERREUR] Echec deploiement sur $server"
  fi
done

# Nettoyer les archives de plus de 1 an
find "$BACKUP_DIR" -name "*.bak" -mtime +365 -delete

echo "Rotation terminee le $DATE"

Pour les equipes et les organisations, la rotation manuelle ne suffit pas. Utilisez des outils comme HashiCorp Vault avec le moteur de secrets SSH pour generer des certificats SSH ephemeres (valides quelques heures) au lieu de cles permanentes. Le principe : les developpeurs s'authentifient aupres de Vault (via SSO/OIDC), qui signe leur cle publique avec l'autorite de certification interne. Le serveur SSH n'a besoin que de la cle publique de la CA, pas de la liste de toutes les cles autorisees.

# Avec HashiCorp Vault : certificats SSH ephemeres
# 1. Signer la cle publique du developpeur (valide 8 heures)
vault write ssh-client-signer/sign/developer \
  public_key=@~/.ssh/id_ed25519.pub \
  valid_principals="deploy" \
  ttl="8h"

# 2. Sauvegarder le certificat
vault write -field=signed_key ssh-client-signer/sign/developer \
  public_key=@~/.ssh/id_ed25519.pub > ~/.ssh/id_ed25519-cert.pub

# 3. Utiliser le certificat pour se connecter
ssh -i ~/.ssh/id_ed25519 production-server
# Le certificat est automatiquement utilise s'il est dans le meme repertoire

# Cote serveur : configurer la CA de confiance
# /etc/ssh/sshd_config
# TrustedUserCAKeys /etc/ssh/trusted-ca.pub
# AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Etape 7 : Surveiller et auditer les connexions SSH en continu

La securite SSH ne s'arrete pas a la configuration. Vous devez surveiller activement les connexions, detecter les tentatives d'intrusion et alerter en temps reel. Trois outils sont essentiels : les logs systeme, fail2ban et les alertes automatisees.

Analysez les logs SSH en temps reel avec journalctl pour detecter les connexions reussies, les echecs et les tentatives de brute-force :

# Suivre les connexions SSH en temps reel
journalctl -u ssh -f

# Compter les tentatives echouees des dernieres 24 heures
journalctl -u ssh --since "24 hours ago" | grep "Failed password" | wc -l

# Lister les IP sources des echecs d'authentification
journalctl -u ssh --since "24 hours ago" | grep "Failed" | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

# Detecter les connexions reussies avec des cles specifiques
journalctl -u ssh --since "7 days ago" | grep "Accepted publickey" | \
  awk '{print $9, $11, $14, $16}'

Configurez fail2ban pour bloquer automatiquement les IP qui echouent trop souvent. Voici une configuration adaptee aux bonnes pratiques 2026 :

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
backend = systemd

# Bannir apres 3 echecs en 10 minutes
maxretry = 3
findtime = 600

# Bannir pour 1 heure (premiere offense)
bantime = 3600

# Bannir incrementalement (recidivistes)
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 604800   # Maximum 1 semaine

# Ignorer les IP internes
ignoreip = 127.0.0.1/8 ::1 10.0.0.0/8 192.168.0.0/16

Mettez en place des alertes automatisees pour les evenements critiques. Un script simple avec un webhook Slack ou une notification email suffit pour les petites equipes :

#!/bin/bash
# /usr/local/bin/ssh-alert.sh
# Declenche par rsyslog ou systemd sur evenement SSH critique

WEBHOOK_URL="https://hooks.slack.com/services/VOTRE/WEBHOOK/URL"

# Alerte sur connexion root reussie
journalctl -u ssh -f | while read line; do
  if echo "$line" | grep -q "Accepted.*root"; then
    curl -s -X POST "$WEBHOOK_URL" \
      -H 'Content-type: application/json' \
      -d "{"text": "ALERTE SSH: Connexion root detectee - $line"}"
  fi
  if echo "$line" | grep -q "Failed.*invalid user"; then
    curl -s -X POST "$WEBHOOK_URL" \
      -H 'Content-type: application/json' \
      -d "{"text": "SSH: Tentative utilisateur invalide - $line"}"
  fi
done

Par ou commencer ?

Si vous ne faites qu'une seule chose aujourd'hui, faites celle-ci : executez l'audit de l'etape 1 sur votre machine et supprimez toutes les cles DSA et RSA inferieures a 3072 bits. Generez une cle Ed25519 avec -a 100 et une passphrase solide. Ces deux actions prennent 10 minutes et eliminent les risques les plus critiques.

La semaine prochaine, appliquez la configuration durcie de l'etape 3 et commandez une cle FIDO2. L'investissement (50 euros pour une YubiKey) est derisoire compare au risque de compromission d'un acces serveur. Pour les equipes, planifiez la migration vers des certificats SSH ephemeres avec Vault sur un horizon de 3 mois.

La cryptographie post-quantique n'est pas une urgence pour 2026, mais c'est une preparation a commencer maintenant. Activez l'echange de cles sntrup761x25519-sha512 des aujourd'hui (il est stable et performant) et testez les signatures ML-DSA hybrides dans un environnement isole. Quand le support sera stabilise dans les distributions, vous serez pret. Pour securiser egalement votre supply chain logicielle, consultez notre guide sur la securisation des pipelines CI/CD GitHub Actions.