Durcir SSH : 10 mesures pour un serveur Linux

SSH est la porte d'entrée de ton serveur Linux. C'est aussi la cible numéro un des attaquants : expose un serveur sur Internet avec le port 22 ouvert, et tu verras les premières tentatives de brute force arriver en moins d'une heure. Bots automatisés, dictionnaires de mots de passe, credential stuffing… le bruit de fond est permanent.

La bonne nouvelle : durcir SSH ne demande ni budget ni outil exotique. Avec une configuration soignée de sshd_config et quelques briques complémentaires, tu élimines l'immense majorité des attaques opportunistes. Voici 10 mesures concrètes, classées par ordre de priorité, avec les directives exactes à appliquer.

Les 10 mesures, dans l'ordre

1. Remplace les mots de passe par des clés ed25519

C'est la mesure qui change tout. Un mot de passe se devine, se brute-force, se réutilise. Une clé ed25519 (courbe elliptique moderne, rapide, clés courtes) est hors de portée de toute attaque par dictionnaire. Génère ta paire de clés côté client, avec une passphrase :

ssh-keygen -t ed25519 -a 100 -C "jean@poste-admin"
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

Le flag -a 100 augmente le nombre de rounds de dérivation de la passphrase : si ta clé privée est volée, elle reste coûteuse à casser. Préfère ed25519 à RSA : à sécurité équivalente, les clés sont plus courtes et les opérations plus rapides. Une fois la connexion par clé validée (depuis un second terminal !), désactive l'authentification par mot de passe :

# /etc/ssh/sshd_config
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

2. Interdis la connexion root directe

Le compte root existe sur tous les serveurs Linux : c'est le premier login que les bots testent. En l'interdisant, tu forces l'attaquant à deviner à la fois un nom d'utilisateur et un secret. Bonus : tu obtiens une traçabilité réelle, chaque admin se connecte avec son propre compte puis élève ses privilèges via sudo.

# /etc/ssh/sshd_config
PermitRootLogin no

Si un outil d'automatisation exige root (sauvegardes, déploiement), utilise PermitRootLogin prohibit-password avec une clé dédiée et restreinte — jamais yes.

3. Restreins les comptes autorisés avec AllowUsers

Par défaut, tout compte local possédant un shell peut tenter une connexion SSH — y compris les comptes de service créés par des paquets. Whiteliste explicitement les comptes légitimes :

# /etc/ssh/sshd_config
AllowUsers admin deploy
# Variante par groupe :
# AllowGroups ssh-users

Tu peux même combiner utilisateur et source : AllowUsers [email protected].* n'autorise le compte admin que depuis ton réseau d'administration (VPN WireGuard, par exemple).

4. Change le port… en connaissant ses limites

Déplacer SSH du port 22 vers un port non standard (par exemple 2222 ou 49152) réduit drastiquement le bruit des scans automatisés dans tes logs. Mais sois lucide : c'est de la réduction de bruit, pas de la sécurité. Un scan complet type nmap -p- -sV retrouve ton port en quelques minutes, et la bannière SSH le trahit immédiatement. Considère cette mesure comme un confort de lecture des logs, jamais comme une protection.

# /etc/ssh/sshd_config
Port 49152

# N'oublie pas le pare-feu AVANT de redémarrer sshd :
ufw allow 49152/tcp
ufw delete allow 22/tcp   # seulement après avoir validé la connexion

5. Installe fail2ban pour bannir les attaquants

fail2ban lit les logs d'authentification en temps réel et bannit (via nftables/iptables) toute IP qui multiplie les échecs. Même avec les mots de passe désactivés, il coupe court aux scans insistants et protège les autres services exposés.

apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = 49152
maxretry = 3
findtime = 10m
bantime  = 1h
# Bannissement progressif : double la durée à chaque récidive
bantime.increment = true

Vérifie le fonctionnement avec fail2ban-client status sshd : tu verras le nombre d'IP actuellement bannies. Sur un serveur exposé, attends-toi à des dizaines par jour.

6. Ajoute un second facteur : MFA TOTP sur SSH

Pour les serveurs sensibles, combine la clé ed25519 avec un code TOTP (Google Authenticator, Aegis, FreeOTP…). Même si la clé privée d'un admin fuit, l'attaquant bute sur le second facteur.

apt install libpam-google-authenticator
google-authenticator   # exécuté par chaque utilisateur, génère le QR code

# /etc/pam.d/sshd — ajouter :
auth required pam_google_authenticator.so

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

La directive AuthenticationMethods publickey,keyboard-interactive exige les deux facteurs successivement : clé d'abord, code TOTP ensuite. Teste impérativement dans un second terminal avant de fermer ta session — c'est la mesure qui provoque le plus de lockouts.

7. Affiche une bannière légale

Une bannière d'avertissement avant authentification n'arrête aucun attaquant, mais elle a une valeur juridique réelle : elle établit que l'accès est restreint et que les connexions sont journalisées, ce qui renforce un dossier en cas de poursuites (article 323-1 du Code pénal sur l'accès frauduleux à un STAD).

# /etc/ssh/sshd_config
Banner /etc/ssh/banner.txt

# /etc/ssh/banner.txt
*** ACCES RESTREINT ***
Ce systeme est reserve aux utilisateurs autorises.
Toute connexion est journalisee. Tout acces non autorise
est passible de poursuites (art. 323-1 et s. du Code penal).

8. Réduis la surface : timeouts, tentatives, fonctionnalités inutiles

Chaque option activée par défaut est une surface d'attaque potentielle. Désactive ce que tu n'utilises pas et limite les fenêtres d'opportunité :

# /etc/ssh/sshd_config
MaxAuthTries 3          # 3 essais max par connexion
LoginGraceTime 30       # 30 s pour s'authentifier, sinon déconnexion
MaxSessions 4
ClientAliveInterval 300 # déconnecte les sessions mortes
ClientAliveCountMax 2
X11Forwarding no        # inutile sur un serveur headless
AllowAgentForwarding no # sauf besoin réel (rebond contrôlé)
AllowTcpForwarding no   # bloque les tunnels pivots
PermitTunnel no

Attention à AllowTcpForwarding no si tu utilises SSH comme bastion ou pour des tunnels légitimes (accès à une base de données interne, par exemple) : applique-le alors par utilisateur via un bloc Match User.

9. Audite régulièrement auth.log

Durcir sans surveiller, c'est piloter sans tableau de bord. Le fichier /var/log/auth.log (ou journalctl -u ssh sur les systèmes systemd récents) raconte tout : qui s'est connecté, d'où, et qui a échoué.

# Connexions réussies
grep "Accepted" /var/log/auth.log

# Échecs et comptes testés par les bots
grep "Failed password\|Invalid user" /var/log/auth.log \
  | awk '{print $NF}' | sort | uniq -c | sort -rn | head

# Top 10 des IP attaquantes
grep "Failed" /var/log/auth.log \
  | grep -oE "from [0-9.]+" | sort | uniq -c | sort -rn | head

Sur un parc de plusieurs machines, centralise ces logs (rsyslog, Wazuh, ou tout SIEM) : une connexion réussie depuis une IP inhabituelle à 3 h du matin doit déclencher une alerte, pas être découverte trois semaines plus tard.

10. Maintiens OpenSSH à jour et vérifie ta config

Les vulnérabilités SSH critiques existent — regreSSHion (CVE-2024-6387) a rappelé en 2024 que même OpenSSH n'est pas infaillible. Active les mises à jour de sécurité automatiques (unattended-upgrades sur Debian/Ubuntu) et prends l'habitude de valider chaque changement :

# Vérifier la syntaxe AVANT de redémarrer
sshd -t

# Voir la configuration effective (defaults inclus)
sshd -T | grep -Ei "permitrootlogin|passwordauth|port|allowusers"

# Appliquer
systemctl restart sshd

Des outils comme ssh-audit te donnent en une commande une note sur tes algorithmes d'échange de clés, de chiffrement et de MAC, avec les recommandations pour écarter les suites obsolètes.

Récapitulatif : un sshd_config durci et commenté

Voici l'assemblage des mesures précédentes, prêt à adapter à ton contexte :

# /etc/ssh/sshd_config — configuration durcie
Port 49152                          # réduction de bruit (pas une protection)
Protocol 2

# --- Authentification ---
PermitRootLogin no                  # jamais root en direct
PubkeyAuthentication yes
PasswordAuthentication no           # clés ed25519 uniquement
PermitEmptyPasswords no
KbdInteractiveAuthentication yes    # requis pour le TOTP
AuthenticationMethods publickey,keyboard-interactive
AllowUsers admin deploy             # whitelist explicite
MaxAuthTries 3
LoginGraceTime 30

# --- Surface d'attaque ---
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
ClientAliveInterval 300
ClientAliveCountMax 2

# --- Légal & logs ---
Banner /etc/ssh/banner.txt
LogLevel VERBOSE                    # journalise les empreintes de clés

Par où commencer ?

Si tu ne dois retenir que trois actions aujourd'hui : passe aux clés ed25519 et désactive les mots de passe (mesure 1), interdis root (mesure 2), installe fail2ban (mesure 5). Ces trois-là neutralisent l'écrasante majorité des attaques réelles observées sur un serveur exposé. Les autres mesures s'ajoutent ensuite, par couches, selon la sensibilité de la machine — c'est exactement le principe de la défense en profondeur.

Et garde le réflexe du pro : chaque modification de sshd_config se fait avec une session de secours ouverte, un sshd -t de validation, et un test de connexion indépendant avant de fermer quoi que ce soit.