Sécuriser SSH : 8 mesures concrètes au-delà du mot de passe

SSH est la porte d'entrée principale de tout serveur Linux. C'est par ce protocole que transitent les commandes d'administration, les déploiements et souvent les transferts de fichiers. Pourtant, la majorité des administrateurs système se contentent de changer le port par défaut et de mettre un mot de passe robuste. C'est insuffisant.

Les attaques par force brute, le credential stuffing et les vulnérabilités protocolaires sont des menaces réelles et quotidiennes. Un serveur exposé sur Internet reçoit en moyenne plusieurs milliers de tentatives de connexion SSH par jour. Dans cet article, je détaille 8 mesures concrètes et éprouvées pour durcir votre configuration SSH, bien au-delà du simple mot de passe.

Chaque mesure est accompagnée de sa configuration exacte et de conseils pratiques issus de mon expérience en production. Toutes les modifications se font dans le fichier /etc/ssh/sshd_config sauf indication contraire.

1. Désactiver l'authentification par mot de passe

La première mesure, et probablement la plus efficace, consiste à supprimer complètement l'authentification par mot de passe. Un mot de passe, aussi complexe soit-il, reste vulnérable aux attaques par dictionnaire et au brute force. Les clés SSH offrent un niveau de checklist sécurité serveur incomparablement supérieur : une clé ED25519 de 256 bits équivaut à un mot de passe de plusieurs dizaines de caractères aléatoires.

Avant de désactiver les mots de passe, assurez-vous d'avoir configuré au moins une clé publique sur le serveur. Testez la connexion par clé dans une session séparée avant de couper l'accès par mot de passe. C'est une erreur classique qui peut vous verrouiller hors de votre propre serveur.

# /etc/ssh/sshd_config

# Désactiver l'authentification par mot de passe
PasswordAuthentication no

# Activer l'authentification par clé publique
PubkeyAuthentication yes

# Désactiver les méthodes d'authentification faibles
ChallengeResponseAuthentication no
UsePAM no

# Redémarrer le service
sudo systemctl restart sshd

Attention : gardez toujours une session SSH ouverte pendant que vous modifiez la configuration. Si vous faites une erreur, vous pourrez corriger sans perdre l'accès. Testez la nouvelle configuration avec sshd -t avant de redémarrer le service.

2. Restreindre les utilisateurs autorisés

Par défaut, SSH autorise la connexion de tous les utilisateurs système qui possèdent un shell valide. C'est une surface d'attaque inutilement large. La directive AllowUsers permet de définir explicitement la liste blanche des comptes autorisés à se connecter. C'est le principe du moindre privilège appliqué à SSH.

Vous pouvez combiner plusieurs approches : restreindre par utilisateur, par groupe, ou exclure certains comptes spécifiques. La directive AllowGroups est particulièrement pratique pour gérer les accès à l'échelle d'une équipe. Créez un groupe dédié comme ssh-users et ajoutez-y uniquement les comptes concernés.

# Autoriser uniquement certains utilisateurs
AllowUsers deployer admin morgann

# Ou restreindre par groupe (plus maintenable)
AllowGroups ssh-users

# Interdire explicitement root (en plus de AllowUsers)
DenyUsers root
PermitRootLogin no

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

Bonne pratique : privilégiez AllowGroups plutôt que AllowUsers en environnement multi-administrateurs. Ajouter ou retirer un utilisateur du groupe est plus simple et moins risqué que de modifier sshd_config à chaque changement d'équipe.

3. Configurer le timeout et les tentatives

Les paramètres de timeout et de limitation des tentatives sont souvent laissés à leurs valeurs par défaut, qui sont trop permissives. LoginGraceTime définit le délai maximum pour s'authentifier après la connexion TCP. MaxAuthTries limite le nombre de tentatives par session. MaxSessions contrôle le nombre de sessions multiplexées sur une seule connexion.

Réduire ces valeurs ralentit considérablement les attaques par brute force et libère plus rapidement les ressources serveur occupées par des connexions malveillantes. Un attaquant qui ne dispose que de 2 tentatives par connexion TCP avec un délai de 30 secondes sera beaucoup moins efficace.

Ces paramètres se combinent efficacement avec pourquoi Fail2ban ne suffit pas pour créer une défense en profondeur. Même si l'attaquant contourne fail2ban en changeant d'adresse IP, les limites de session restent actives.

# Timeout et limitations de session
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 3

# Déconnexion automatique des sessions inactives
ClientAliveInterval 300
ClientAliveCountMax 2

# Désactiver le forwarding si non nécessaire
AllowTcpForwarding no
X11Forwarding no
AllowAgentForwarding no

Astuce : ClientAliveInterval 300 combiné à ClientAliveCountMax 2 déconnecte automatiquement les sessions inactives après 10 minutes (300s x 2). C'est essentiel pour éviter les sessions fantômes qui restent ouvertes indéfiniment.

4. Activer le 2FA avec Google Authenticator

L'authentification à deux facteurs ajoute une couche de sécurité fondamentale : même si un attaquant obtient votre clé privée (vol de laptop, compromission de poste), il lui faudra également le code TOTP généré par votre application d'authentification. C'est la défense en profondeur dans sa forme la plus concrète.

Le module PAM libpam-google-authenticator s'intègre parfaitement avec OpenSSH. La configuration impose de fournir à la fois la clé SSH et un code TOTP pour se connecter. Le temps de configuration est d'environ 5 minutes par serveur.

# Installation du module PAM
sudo apt install libpam-google-authenticator

# Configuration par utilisateur
google-authenticator -t -d -f -r 3 -R 30 -w 3

# /etc/pam.d/sshd - Ajouter en fin de fichier
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
UsePAM yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

# Redémarrer SSH
sudo systemctl restart sshd

Important : générez et conservez les codes de secours dans un endroit sûr (gestionnaire de mots de passe, coffre-fort). Sans ces codes, la perte de votre téléphone signifie la perte d'accès au serveur. J'ai détaillé la procédure complète dans mon article dédié au 2FA sur SSH.

5. Utiliser des clés ED25519 au lieu de RSA

RSA a été le standard pendant des décennies, mais ED25519 le surpasse sur tous les plans. Les clés ED25519 sont plus courtes (256 bits contre 4096 bits pour un RSA équivalent en sécurité), la signature est plus rapide, et l'algorithme est résistant aux attaques par canal auxiliaire. De plus, ED25519 utilise des courbes elliptiques dont les paramètres ne sont pas suspects, contrairement à NIST P-256.

La migration est simple : générez une nouvelle paire de clés ED25519, déployez la clé publique sur vos serveurs, puis supprimez les anciennes clés RSA. Profitez-en pour configurer le serveur afin qu'il n'accepte que les algorithmes modernes et refuse les anciens algorithmes de chiffrement vulnérables.

# Générer une clé ED25519 avec commentaire
ssh-keygen -t ed25519 -C "morgann@workstation-2026" -a 100

# Copier la clé sur le serveur
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@serveur

# Restreindre les algorithmes côté serveur dans sshd_config
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com

# Supprimer les anciennes clés hôte RSA/DSA/ECDSA
sudo rm /etc/ssh/ssh_host_rsa_key*
sudo rm /etc/ssh/ssh_host_dsa_key*
sudo rm /etc/ssh/ssh_host_ecdsa_key*

# Régénérer uniquement la clé hôte ED25519
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo systemctl restart sshd

Note : l'option -a 100 lors de la génération augmente le nombre d'itérations KDF pour protéger la clé privée sur disque. C'est une protection supplémentaire si votre fichier de clé privée est compromis : le brute force de la passphrase sera 100 fois plus lent.

6. Port knocking et fail2ban

Le port knocking est une technique de sécurité par obscurité qui, combinée à de vraies mesures de sécurité, ajoute une couche de protection efficace. Le principe est simple : le port SSH reste fermé par défaut. Il ne s'ouvre que lorsque le client envoie une séquence précise de connexions sur d'autres ports. C'est l'équivalent numérique d'un code à frapper sur une porte.

Fail2ban, quant à lui, surveille les logs d'authentification et bannit temporairement les adresses IP qui échouent trop souvent. C'est la mesure la plus répandue et pour cause : elle est simple à mettre en place et immédiatement efficace contre le brute force automatisé.

Ces deux outils se complètent parfaitement. Le port knocking réduit drastiquement le bruit dans les logs, et fail2ban gère les tentatives qui passent malgré tout.

# Installation de fail2ban
sudo apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

# Port knocking avec knockd
sudo apt install knockd

# /etc/knockd.conf
[openSSH]
    sequence    = 7000,8000,9000
    seq_timeout = 5
    command     = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
    tcpflags    = syn

[closeSSH]
    sequence    = 9000,8000,7000
    seq_timeout = 5
    command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
    tcpflags    = syn

# Côté client : frapper avant de se connecter
knock serveur 7000 8000 9000 && ssh user@serveur

Conseil : fail2ban avec bantime = 3600 et maxretry = 3 est un bon point de départ. Pour les serveurs très exposés, envisagez un ban progressif avec bantime.increment = true qui double la durée de bannissement à chaque récidive. J'ai écrit un guide complet sur la configuration avancée de fail2ban.

7. Journalisation et alertes

Une configuration SSH durcie ne sert à rien si personne ne surveille les logs. Par défaut, OpenSSH journalise avec un niveau de verbosité minimal. Passer en VERBOSE permet d'enregistrer les empreintes des clés utilisées, les tentatives échouées détaillées et les informations de session complètes. Ces données sont essentielles pour l'analyse post-incident.

Au-delà de la journalisation passive, mettez en place des alertes actives. Un script simple qui surveille les connexions réussies et envoie une notification permet de détecter immédiatement une intrusion. Combiné à un outil de centralisation de logs comme rsyslog ou journald, vous obtenez une visibilité complète sur l'activité SSH.

# /etc/ssh/sshd_config - Journalisation avancée
LogLevel VERBOSE
SyslogFacility AUTH

# Script d'alerte sur connexion réussie
# /etc/ssh/notify-login.sh
#!/bin/bash
SUBJECT="Alerte SSH : connexion sur $(hostname)"
BODY="Utilisateur: $PAM_USER\nIP source: $PAM_RHOST\nDate: $(date)"
echo -e "$BODY" | mail -s "$SUBJECT" admin@example.com

# /etc/pam.d/sshd - Déclencher le script
session optional pam_exec.so /etc/ssh/notify-login.sh

# Surveiller les connexions en temps réel
journalctl -u sshd -f --output=short-precise

# Compter les tentatives échouées des dernières 24h
journalctl -u sshd --since "24 hours ago" | grep "Failed password" | wc -l

Astuce : le niveau VERBOSE enregistre l'empreinte (fingerprint) de chaque clé utilisée pour se connecter. C'est inestimable pour identifier quelle clé a été utilisée en cas d'incident, surtout si plusieurs personnes partagent un même compte de service.

8. Auditer régulièrement la configuration

La sécurité n'est pas un état, c'est un processus. Une configuration durcie aujourd'hui peut devenir vulnérable demain suite à une mise à jour, un changement de politique ou la découverte d'une nouvelle faille. L'audit régulier de votre configuration SSH est indispensable pour maintenir un niveau de sécurité constant.

L'outil ssh-audit analyse la configuration de votre serveur SSH et identifie les algorithmes faibles, les paramètres obsolètes et les bonnes pratiques manquantes. Lynis, quant à lui, réalise un audit de sécurité global du système incluant SSH. Intégrez ces outils dans vos routines de maintenance ou, mieux encore, dans votre pipeline CI/CD.

Planifiez un audit mensuel au minimum. Automatisez-le avec cron et envoyez les rapports par courriel. Les résultats de ssh-audit peuvent être intégrés dans votre outil de monitoring pour déclencher des alertes si le score de sécurité se dégrade.

# Installation de ssh-audit
pip install ssh-audit

# Auditer le serveur local
ssh-audit localhost

# Auditer un serveur distant
ssh-audit serveur.example.com

# Audit avec Lynis (section SSH)
sudo apt install lynis
sudo lynis audit system --tests-from-group ssh

# Automatiser l'audit mensuel via cron
# /etc/cron.monthly/ssh-audit.sh
#!/bin/bash
REPORT="/var/log/ssh-audit-$(date +%Y%m).txt"
ssh-audit localhost > "$REPORT" 2>&1
mail -s "Rapport SSH audit - $(hostname)" admin@example.com < "$REPORT"

# Vérifier la syntaxe de la configuration
sudo sshd -t

# Lister les algorithmes actifs
ssh -Q cipher
ssh -Q mac
ssh -Q kex

Rappel : après chaque mise à jour d'OpenSSH, relancez ssh-audit pour vérifier que de nouveaux algorithmes n'ont pas été activés par défaut. Les mises à jour de sécurité corrigent des failles mais peuvent aussi réactiver des options que vous aviez volontairement désactivées.

Récapitulatif et prochaines étapes

Voici un résumé des 8 mesures à appliquer pour durcir votre configuration SSH :

• Désactiver les mots de passe : authentification par clé uniquement
• Restreindre les utilisateurs : AllowGroups avec un groupe dédié
• Limiter les tentatives : MaxAuthTries, timeout et déconnexion automatique
• Activer le 2FA : clé SSH + code TOTP obligatoire
• Utiliser ED25519 : abandonner RSA et les algorithmes obsolètes
• Déployer fail2ban : bannissement automatique des attaquants
• Journaliser en VERBOSE : traçabilité complète des connexions
• Auditer régulièrement : ssh-audit et lynis en routine mensuelle

Ces mesures, appliquées ensemble, réduisent drastiquement la surface d'attaque de votre serveur. Aucune d'entre elles n'est complexe à mettre en place, et chacune apporte une couche de protection supplémentaire. La sécurité se construit en profondeur : ce n'est pas une seule mesure qui vous protège, c'est leur combinaison.

Pour aller plus loin, je vous recommande de consulter le site officiel de ssh-audit qui maintient une liste à jour des algorithmes recommandés, ainsi que les pages man d'OpenSSH pour une référence complète de toutes les directives disponibles.