Gabriele SalatiSysadmin, vie privée et self-hosting

← Tous les articles ·

Secure Shell Daemon & Crypto

Le serveur OpenSSH est un outil fondamental pour garantir des communications sûres sur des réseaux non fiables. Le protocole SSH permet aux administrateurs de gérer serveurs et machines à distance via un terminal bash, en utilisant une connexion totalement protégée.

La configuration et la mise en sécurité correctes d’OpenSSH sont cruciales : un serveur SSH mal configuré peut devenir la porte d’entrée pour des attaquants. Dans cet article, on voit comment configurer OpenSSH pour obtenir le niveau maximal de sécurité, en excluant les algorithmes obsolètes et en n’utilisant que de la cryptographie moderne et robuste.

Principes de sécurité SSH

Avant d’entrer dans les détails techniques, il est important de comprendre les principes de base de la sécurité SSH :

  • Utilisation exclusive du Protocol 2 : le Protocol 1 est obsolète et vulnérable
  • Clés fortes : seulement RSA (4096 bits) et Ed25519
  • Exclusion des algorithmes faibles : pas de DSA, ECDSA avec courbes NIST, SHA1 ou MD5
  • Perfect Forward Secrecy : protection des communications passées même si une clé est compromise

1. Préparation du serveur : suppression des clés par défaut

La première étape fondamentale est de supprimer toutes les clés par défaut générées lors de l’installation d’OpenSSH. Ces clés pourraient être faibles ou basées sur des algorithmes obsolètes.

On exécute ces commandes pour éliminer les anciennes clés et en générer de nouvelles, sûres :

# On se place dans le répertoire SSH
cd /etc/ssh

# On supprime TOUTES les clés existantes
rm ssh_host_*key*

# On génère une nouvelle clé Ed25519 (la plus sûre)
ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null

# On génère une clé RSA robuste (4096 bits)
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null

Note importante : après cette opération, les clients qui s’étaient déjà connectés au serveur recevront un avertissement de changement de clé. C’est normal et attendu.

2. Configuration du protocole et des clés hôte

Dans le fichier /etc/ssh/sshd_config, on impose l’usage exclusif du Protocol 2 et on indique quelles clés utiliser :

# Utilise seulement le protocole sûr
Protocol 2

# Spécifie uniquement les clés sûres
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

3. Algorithmes d’échange de clés (Key Exchange)

L’échange de clés est le moment le plus critique de la connexion SSH. Pendant cette phase, client et serveur se mettent d’accord sur une clé secrète partagée qui sera utilisée pour chiffrer toute la communication.

On utilise uniquement des algorithmes qui garantissent Perfect Forward Secrecy et qui ne sont pas soupçonnés de contenir des backdoors :

# Dans /etc/ssh/sshd_config
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Pourquoi ces choix ?

  • curve25519-sha256 : courbe elliptique moderne, non compromise par le NIST
  • diffie-hellman-group-exchange-sha256 : version sûre du classique Diffie-Hellman avec SHA256
  • Courbes NIST exclues : soupçonnées de contenir des backdoors NSA

4. Algorithmes d’authentification : pourquoi éviter DSA et ECDSA

Problèmes avec DSA

Les clés DSA sont limitées à 1024 bits, une taille considérée comme insuffisante depuis 2010. Elles sont vulnérables à :

  • Des attaques de factorisation avec du hardware moderne
  • Des vulnérabilités dans la génération de nombres aléatoires

Problèmes avec ECDSA

ECDSA présente deux soucis principaux :

Les alternatives sûres : Ed25519 et RSA

Ed25519 est l’évolution sûre d’ECDSA :

  • Utilise la courbe Curve25519, non compromise
  • Excellentes performances
  • Résistant aux attaques side-channel

RSA avec des clés de 4096 bits reste sûr si :

  • On utilise des clés d’au moins 4096 bits
  • On évite RSA-SHA1 pour les nouvelles implémentations

5. Configuration de l’authentification client

Génération des clés client

Côté client, on génère les deux types de clés sûres :

# Clé Ed25519 (recommandée)
ssh-keygen -t ed25519

# Clé RSA de backup
ssh-keygen -t rsa -b 4096

Important : protège toujours les clés privées avec une passphrase robuste !

Envoi de la clé publique au serveur

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@hostname

Désactivation de l’authentification par mot de passe

Une fois l’authentification par clé configurée, on désactive immédiatement les mots de passe :

# Dans /etc/ssh/sshd_config
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

6. Chiffres pour la protection des données

Après l’authentification, les données sont chiffrées. On n’utilise que des chiffres modernes et sûrs :

# Dans /etc/ssh/sshd_config
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Pourquoi ces chiffres ?

  • chacha20-poly1305 : chiffre stream moderne, rapide et sûr
  • aes-gcm : mode authentifié d’AES, combine chiffrement et authentification
  • aes-ctr : mode counter d’AES, sûr et parallélisable

7. MACs pour l’intégrité des données

Les Message Authentication Codes (MACs) garantissent que les données ne sont pas modifiées en transit :

# Dans /etc/ssh/sshd_config
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

Notes importantes sur les MACs :

  • On n’utilise que SHA2-256 et SHA2-512 (SHA1 et MD5 sont vulnérables aux attaques par collision)
  • Les versions « etm » (Encrypt-then-MAC) sont préférables pour la sécurité
  • Taille minimale : 128 bits pour les clés et les tags

8. Configuration client

Dans le fichier ~/.ssh/config du client, on reproduit les paramètres de sécurité :

Host *
    # Protocole et authentification
    PubkeyAuthentication yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no

    # Algorithmes d’authentification hôte
    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

    # Échange de clés
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

    # Chiffres
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

    # MACs
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

9. Vérification de la configuration

Après avoir appliqué toutes les modifications :

# Test de la configuration
sshd -t

# Restart du service
systemctl restart sshd

# Vérification des algorithmes actifs
ssh -Q kex
ssh -Q cipher
ssh -Q mac

10. Mesures de sécurité supplémentaires

Limiter les accès

# N’autoriser que des utilisateurs spécifiques
AllowUsers admin developer

# Ou n’autoriser que des groupes spécifiques
AllowGroups ssh-users

# Désactiver le login root
PermitRootLogin no

Protection contre les attaques brute force

# Nombre maximum de tentatives
MaxAuthTries 3

# Temps maximum pour s’authentifier
LoginGraceTime 20

# Nombre maximum de sessions
MaxSessions 2

11. Protection supplémentaire : custom chain iptables anti-bruteforce

Comme protection supplémentaire, on configure une chaîne iptables personnalisée pour limiter les tentatives de bruteforce sur SSH. On utilise le port 22222 au lieu du standard 22.

D’abord on modifie le port dans /etc/ssh/sshd_config :

Port 22222

Puis on crée la custom chain avec iptables :

# On crée une nouvelle chaîne appelée SSH_BRUTEFORCE
iptables -N SSH_BRUTEFORCE

# Dans la chaîne, on trace les nouvelles connexions avec le module recent
# Chaque IP est mémorisée dans la liste "sshbrute"
iptables -A SSH_BRUTEFORCE -m recent --name sshbrute --set

# Si une IP tente plus de 3 connexions en 60 secondes, elle est droppée
iptables -A SSH_BRUTEFORCE -m recent --name sshbrute --update --seconds 60 --hitcount 3 -j DROP

# Si l’IP respecte le rate limit, on accepte la connexion
iptables -A SSH_BRUTEFORCE -j ACCEPT

# On redirige le trafic TCP sur le port 22222 vers notre custom chain
iptables -A INPUT -p tcp --dport 22222 -m state --state NEW -j SSH_BRUTEFORCE

Comment ça marche :

  • Le module recent garde la trace des IPs qui tentent de se connecter
  • Chaque nouvelle tentative de connexion est enregistrée avec --set
  • --hitcount 3 compte les tentatives : à la troisième en 60 secondes, l’IP est bloquée
  • Après 60 secondes le compteur se réinitialise automatiquement

Pour rendre les règles persistantes au redémarrage :

# Sur systèmes Debian/Ubuntu
iptables-save > /etc/iptables/rules.v4

# Sur systèmes RedHat/CentOS
service iptables save

Cette configuration simple bloque efficacement les attaques bruteforce automatisées, en permettant au maximum 2 tentatives de login par minute pour chaque IP.

Conclusions

Cette configuration d’OpenSSH offre le niveau maximal de sécurité actuellement disponible, en excluant tous les algorithmes faibles ou suspects. N’oublie pas de :

  • Maintenir OpenSSH toujours à jour
  • Surveiller les logs système pour des activités suspectes
  • Revoir périodiquement la configuration à la lumière de nouvelles vulnérabilités
  • Toujours utiliser des passphrases solides pour les clés privées

La sécurité n’est pas un produit mais un processus : cette configuration est un excellent point de départ, mais elle demande maintenance et mises à jour constantes.