Durcissement SSH — au-delà des clés publiques

L’authentification par clé publique constitue une première ligne de défense solide face aux attaques par force brute sur SSH. Mais si l’on s’arrête là, on laisse ouvertes de nombreuses surfaces d’attaque : algorithmes cryptographiques obsolètes, sessions non limitées, absence de journalisation fine, ou encore aucune protection contre les connexions légitimes mais compromises. Un serveur SSH mal configuré expose l’ensemble de l’infrastructure.

Ce guide explore les niveaux de durcissement souvent négligés : restrictions cryptographiques, contrôle d’accès fin, authentification multi-facteurs, certificats SSH et détection d’intrusion. Toutes les procédures sont testées sur Debian 12 (Bookworm) et Ubuntu 24.04 LTS.

Avant toute modification, ouvrez une seconde session SSH de secours et validez chaque changement avec sudo sshd -t avant de redémarrer le service. Un fichier de configuration invalide peut vous verrouiller définitivement hors du serveur.

1. Renforcer les algorithmes cryptographiques

OpenSSH active par défaut des algorithmes de compatibilité ascendante, dont certains sont considérés comme faibles. Créez un fichier de surcharge dédié pour ne pas toucher au fichier principal :

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

Ajoutez-y le bloc suivant, conforme aux recommandations ANSSI BP-028 :

# Échange de clés : uniquement courbes modernes
KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

# Chiffrements symétriques : AEAD uniquement
Ciphers [email protected],[email protected],[email protected]

# Codes d'authentification de message
MACs [email protected],[email protected],hmac-sha2-512

# Algorithmes de clé hôte : Ed25519 en priorité
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Algorithmes acceptés pour les clés publiques clients
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

Pour regénérer vos clés hôtes en Ed25519 si ce n’est pas encore fait :

sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

Vérifiez l’exposition de votre serveur avec ssh-audit :

sudo apt install ssh-audit
ssh-audit localhost

2. Paramètres avancés de sshd_config

Au-delà des algorithmes, de nombreuses directives permettent de réduire drastiquement la surface d’attaque :

# Désactiver le login root direct
PermitRootLogin no

# Authentification par mot de passe désactivée
PasswordAuthentication no
PermitEmptyPasswords no

# Limiter les tentatives et le délai de connexion
MaxAuthTries 3
LoginGraceTime 30

# Sessions simultanées par connexion
MaxSessions 2
MaxStartups 10:30:60

# Désactiver les fonctionnalités inutiles
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
GatewayPorts no

# Journalisation renforcée
LogLevel VERBOSE
SyslogFacility AUTH

# Timeout de session inactive (5 min sans activité = déconnexion)
ClientAliveInterval 300
ClientAliveCountMax 2

Restreindre l’accès par utilisateur ou groupe

Le paramètre AllowUsers est l’une des protections les plus efficaces : seuls les utilisateurs listés peuvent se connecter, peu importe leurs autres droits système :

# Autoriser uniquement deux utilisateurs
AllowUsers alice bob

# Ou par groupe (recommandé en production)
AllowGroups ssh-users admins

# Créer le groupe et y ajouter un utilisateur
sudo groupadd ssh-users
sudo usermod -aG ssh-users alice

Changer le port d’écoute

Changer le port par défaut (22) réduit significativement le bruit dans les logs, sans être une protection en soi. Adaptez également votre pare-feu :

Port 2222

# Ouvrir le nouveau port avec nftables avant de fermer l'ancien
sudo nft add rule inet filter input tcp dport 2222 accept

Rechargez ensuite la configuration :

sudo sshd -t && sudo systemctl restart ssh

3. Authentification multi-facteurs (2FA) avec TOTP

Combiner clé publique et TOTP (Time-based One-Time Password) élimine le risque de compromission de clé privée seule. L’implémentation repose sur PAM et le module Google Authenticator :

sudo apt install libpam-google-authenticator

Chaque utilisateur devant activer le 2FA exécute :

google-authenticator -t -d -f -r 3 -R 30 -w 3

Scannez le QR code avec une application TOTP (FreeOTP, Aegis, etc.).

Configurez PAM pour SSH :

sudo nano /etc/pam.d/sshd

# Ajouter en fin de fichier (avant @include)
auth required pam_google_authenticator.so nullok

Ajoutez dans /etc/ssh/sshd_config.d/99-hardening.conf :

UsePAM yes
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Avec cette configuration, la connexion exige à la fois une clé valide et le code TOTP.

4. Autorité de certification SSH (SSH CA)

Dans un parc de serveurs, gérer un fichier authorized_keys par machine devient rapidement ingérable. Les certificats SSH résolvent ce problème : une autorité de certification signe les clés des utilisateurs, et chaque serveur fait confiance au CA — une seule ligne de configuration côté serveur.

Créer une CA et signer une clé utilisateur

# Générer la paire de clés CA (à conserver hors ligne ou sur un bastion)
ssh-keygen -t ed25519 -f /etc/ssh/ssh_ca -C "SSH CA libra-linux.com"

# Déposer la clé publique CA sur les serveurs cibles
sudo cp /etc/ssh/ssh_ca.pub /etc/ssh/

# Dans sshd_config.d/99-hardening.conf
TrustedUserCAKeys /etc/ssh/ssh_ca.pub

# Signer la clé publique d'un utilisateur (validité 30 jours)
ssh-keygen -s /etc/ssh/ssh_ca 
  -I "[email protected]" 
  -n alice 
  -V +30d 
  ~/.ssh/id_ed25519.pub

L’utilisateur obtient alors un fichier id_ed25519-cert.pub. Aucune modification du fichier authorized_keys n’est nécessaire sur le serveur.

5. Protection contre la force brute avec Fail2Ban

Même avec les authentifications par clé et TOTP, les tentatives de connexion malveillantes polluent les logs et sollicitent inutilement le serveur. Fail2Ban analyse les journaux et bloque automatiquement les IP suspectes :

sudo apt install fail2ban

sudo nano /etc/fail2ban/jail.d/sshd.conf

[sshd]
enabled  = true
port     = 2222
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
findtime = 600
bantime  = 3600
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

6. Restrictions fines avec la directive Match

La directive Match permet d’appliquer des règles différentes selon l’utilisateur, le groupe, l’adresse IP source ou le nom d’hôte. Cas d’usage typique : un compte de déploiement limité à une commande unique :

Match User deploy
    ForceCommand /usr/local/bin/deploy.sh
    AllowTcpForwarding no
    X11Forwarding no
    PermitTTY no

Match Address 10.0.0.0/8
    AllowTcpForwarding yes
    PermitTunnel yes

La directive ForceCommand est particulièrement utile pour les comptes de sauvegarde ou d’intégration continue : la clé SSH ne peut exécuter que le script autorisé, quelle que soit la commande envoyée par le client.

7. Auditer la configuration avec ssh-audit

Une fois la configuration appliquée, validez-la avec ssh-audit, qui teste les algorithmes réellement annoncés par le serveur :

# Audit en local
ssh-audit -p 2222 localhost

# Audit depuis un poste distant
ssh-audit -p 2222 votre-serveur.example.com

Les lignes en rouge ou orange indiquent des algorithmes à désactiver. L’objectif est d’obtenir uniquement des lignes vertes dans les sections kex, enc et mac.

Pensez également à Lynis pour un audit de sécurité global du système :

sudo apt install lynis
sudo lynis audit system

À lire également

• Authentification par clé publique sur un serveur SSH — les fondamentaux avant d’appliquer ce guide
• nftables en pratique — remplacer iptables sur Debian/Ubuntu — pare-feu complémentaire au durcissement SSH
• Ansible : automatiser la gestion de serveurs Linux avec des playbooks — déployer la configuration SSH sur un parc
• WireGuard : monter un VPN mesh entre plusieurs serveurs Linux — restreindre SSH derrière un VPN

Références

• Documentation officielle sshd_config (OpenBSD)
• ssh-audit — Hardening Guides (SSH Audit)
• Comment durcir OpenSSH sur Ubuntu (DigitalOcean)
• Note technique OpenSSH — ANSSI