Sécuriser un serveur SSH : le durcissement qui tient

Sécuriser un serveur SSH repose sur cinq gestes ordonnés : authentification par clé au lieu du mot de passe, désactivation de la connexion root, restriction des utilisateurs autorisés, blocage des IP fautives avec Fail2ban et filtrage par pare-feu. Appliqués dans cet ordre, ils transforment un service exposé en porte verrouillée. Chaque geste ferme une surface d’attaque différente.

Un serveur SSH connecté à Internet subit des tentatives de connexion dès sa première heure en ligne. Les robots scannent en continu le port 22, testent des identifiants volés et enchaînent les mots de passe courants. D’après le rapport Elastic Global Threat Report 2024, les attaques par force brute représentent 89 % des comportements malveillants observés sur les systèmes Linux, et les points d’accès SSH exposés en sont la cible première. Le durcissement ne relève donc pas de la paranoïa : c’est une hygiène de base.

Pourquoi SSH concentre les attaques

SSH (Secure Shell) donne un accès complet au serveur : lecture, écriture, exécution de commandes, contrôle des services. Un attaquant qui obtient une session SSH valide contrôle la machine entière. Cette valeur en fait la cible la plus recherchée sur les serveurs exposés.

Le protocole chiffre solidement les échanges. Le maillon faible n’est jamais le chiffrement, c’est l’authentification. Un mot de passe deviné, une clé volée ou un compte oublié suffisent à contourner toute la cryptographie. Les campagnes d’attaque le prouvent par leur ampleur : Cisco Talos a documenté en 2024 une campagne de force brute qui a enregistré plus de 12 millions de tentatives depuis 169 pays en seulement onze jours.

La logique des attaquants est industrielle. Ils ne visent pas un serveur en particulier, ils balaient des plages d’adresses entières à la recherche de la configuration la plus faible. Un serveur mal durci ressort du lot en quelques minutes. Le durcissement ne vous rend pas invisible, il vous fait sortir de la catégorie des cibles faciles.

Passer à l’authentification par clé

Le premier geste, et le plus efficace, remplace le mot de passe par une paire de clés cryptographiques. Une clé privée reste sur votre poste, une clé publique est déposée sur le serveur. Sans la clé privée, aucune force brute ne fonctionne : il n’y a plus de mot de passe à deviner.

Générez une paire de clés modernes. L’algorithme Ed25519 produit des clés courtes, rapides et robustes, préférables au RSA sauf contrainte de compatibilité ancienne :

ssh-keygen -t ed25519 -C "admin@monserveur"
ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@serveur

Une fois la connexion par clé testée et fonctionnelle, coupez l’authentification par mot de passe dans le fichier /etc/ssh/sshd_config :

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Rechargez ensuite le service avec systemctl reload sshd. Avant de fermer votre session actuelle, ouvrez une seconde connexion pour vérifier que la clé fonctionne. Une erreur dans ce fichier peut vous verrouiller dehors. Gardez toujours un accès console de secours chez votre hébergeur : la console KVM ou le mode rescue permet de corriger une configuration cassée sans SSH.

Protégez la clé privée par une phrase de passe. Si votre poste est compromis, cette phrase ajoute une barrière avant que la clé ne serve. Un agent SSH la garde en mémoire pour la session, vous ne la tapez qu’une fois.

Désactiver la connexion root

Le compte root a tous les pouvoirs. Autoriser sa connexion directe en SSH revient à offrir aux attaquants une cible dont ils connaissent déjà le nom. Toutes les tentatives de force brute testent root en premier.

La règle : se connecter avec un compte utilisateur normal, puis élever les privilèges avec sudo. Dans sshd_config :

PermitRootLogin no
AllowUsers admin deploy

La directive AllowUsers limite l’accès SSH à une liste blanche de comptes. Tout autre utilisateur, même avec un mot de passe correct, est refusé au niveau du serveur. Cette restriction ferme les comptes de service, les comptes système et les comptes oubliés qui traînent souvent sur une machine ancienne.

Vérifiez qu’un compte administrateur dispose bien de sudo avant de couper root. Sur Debian et Ubuntu, ajoutez l’utilisateur au groupe adéquat :

usermod -aG sudo admin

Cette séparation entre compte de connexion et privilège root trace aussi chaque action. Sudo journalise les commandes privilégiées, ce que la connexion root directe ne fait pas. En cas d’incident, ces journaux disent qui a fait quoi. La gestion des utilisateurs et des permissions forme la base de cette discipline.

Changer le port et réduire le bruit

Le port 22 est le port par défaut de SSH. C’est aussi le premier que scannent tous les robots. Déplacer le service vers un port haut, entre 1024 et 65535, ne rend pas le serveur invulnérable mais réduit drastiquement le volume de tentatives automatisées.

Dans sshd_config, changez la ligne du port :

Port 2222

Le gain est réel sur les journaux : un serveur sur le port 22 accumule des centaines de lignes d’échec par jour, un serveur sur un port haut en compte une poignée. Des journaux plus propres rendent une vraie intrusion plus visible. Le bruit de fond disparaît, l’anomalie ressort.

Cette mesure reste cosmétique face à un attaquant ciblé, qui scanne toutes les plages de ports. Elle se combine avec le reste, elle ne remplace rien. Pensez à ouvrir le nouveau port sur le pare-feu avant de recharger SSH, sinon la prochaine connexion échoue.

Trois réglages supplémentaires resserrent les sessions :

• Délai d’inactivité : ClientAliveInterval 300 et ClientAliveCountMax 2 coupent une session inactive après dix minutes
• Tentatives limitées : MaxAuthTries 3 déconnecte après trois échecs d’authentification
• Sessions parallèles : MaxSessions 2 plafonne le nombre de canaux par connexion

Bloquer les IP fautives avec Fail2ban

Fail2ban surveille les journaux d’authentification et bannit temporairement les adresses qui accumulent des échecs. C’est la réponse dynamique aux attaques par force brute qui persistent malgré les clés. Une IP qui échoue cinq fois se voit bloquée au niveau du pare-feu pendant une durée définie.

L’installation est directe sur Debian et Ubuntu :

apt install fail2ban
systemctl enable --now fail2ban

La configuration se place dans un fichier /etc/fail2ban/jail.local pour ne pas écraser les réglages par défaut lors des mises à jour :

[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 3600
findtime = 600

Ici, trois échecs en dix minutes déclenchent un bannissement d’une heure. Ajustez bantime vers le haut pour une IP récidiviste : certains administrateurs configurent un bannissement progressif qui allonge la durée à chaque récidive. La commande fail2ban-client status sshd liste les adresses actuellement bloquées.

Fail2ban a ses limites. Il agit après l’échec, pas avant. Il ne protège pas contre une clé légitimement volée, ni contre une attaque distribuée qui change d’IP à chaque tentative. Sa valeur : éliminer le flot des robots simples qui saturent les journaux. Ces mécanismes de blocage automatique font partie de l’arsenal général pour protéger un serveur des cybermenaces.

Filtrer par pare-feu et couches supplémentaires

Le pare-feu décide qui peut atteindre le service SSH avant même que l’authentification commence. C’est la couche la plus solide, car elle rejette le trafic non désiré au niveau réseau. Fail2ban réagit aux échecs, le pare-feu les empêche d’arriver.

La configuration de base avec UFW sur Ubuntu :

ufw allow 2222/tcp
ufw enable

Activer le pare-feu avant d’autoriser SSH risque de couper la connexion en cours. Autorisez toujours le port SSH en premier. Si votre adresse IP est fixe, restreignez encore l’accès à cette seule source :

ufw allow from 203.0.113.10 to any port 2222 proto tcp

Cette règle transforme le serveur en forteresse : seule votre IP de confiance atteint le port SSH, tout le reste du monde reçoit un rejet silencieux. Un pare-feu ainsi verrouillé rend même Fail2ban presque superflu, puisque les robots n’atteignent plus le service.

Le tableau suivant récapitule le rôle de chaque couche et ce qu’elle protège :

Pour les serveurs qui hébergent des données sensibles, une authentification à deux facteurs vient renforcer SSH lui-même. Un module comme Google Authenticator ajoute un code temporaire à la clé. Le principe rejoint celui du déploiement de l’authentification multifacteur en entreprise : une clé volée seule ne suffit plus.

L’exposition du service compte aussi. Un serveur SSH accessible depuis n’importe où reste plus vulnérable qu’un accès réservé au réseau interne. Sur une infrastructure domestique ou en télétravail, placer SSH derrière un accès contrôlé participe à l’optimisation et la sécurisation du réseau.

Vérifier et maintenir dans le temps

Le durcissement n’est pas un réglage unique, c’est un état à maintenir. Après chaque modification de sshd_config, testez la configuration avant de recharger :

sshd -t

Cette commande valide la syntaxe et refuse de recharger un fichier cassé. Elle évite le scénario classique : un point-virgule mal placé qui verrouille l’accès. Gardez une session ouverte pendant les tests, ouvrez-en une seconde pour valider, et ne fermez la première qu’une fois la nouvelle confirmée.

Surveillez les journaux d’authentification pour détecter les schémas d’attaque. La commande journalctl -u ssh -f suit les connexions en temps réel. Un pic soudain de tentatives depuis une plage d’IP inhabituelle mérite attention. Les mises à jour du serveur OpenSSH corrigent régulièrement des failles : maintenir le paquet à jour ferme les vulnérabilités connues avant qu’elles ne soient exploitées.

Prochaine étape : appliquer ces cinq gestes dans l’ordre sur votre serveur, en gardant un accès de secours à chaque phase, puis programmer une revue trimestrielle des comptes autorisés et des règles de pare-feu. Un serveur durci qu’on ne surveille plus dérive en six mois vers un serveur oublié.