La sécurisation d’un serveur Debian passe par une configuration rigoureuse d’OpenSSH et des composants associés. Ces réglages réduisent l’exposition aux robots de scan et aux attaques par force brute.
L’objectif est de présenter des mesures pragmatiques et vérifiables pour la production et l’exploitation. Ces bonnes pratiques précises conduisent aux points essentiels présentés ci‑dessous.
A retenir :
- Port non standard pour SSH, diminution notable des scans automatiques externes
- Authentification par clé publique uniquement, élimination des mots de passe vulnérables
- Listes blanches d’utilisateurs et de groupes, administration centralisée des accès
- Surveillance des journaux, alertes automatiques et blocage via fail2ban ou équivalent
Après le choix stratégique, sshd_config : ports, protocole et chiffrement OpenSSH
Port SSH et protocole recommandé pour Debian
Ce point explique pourquoi déplacer le port par défaut réduit le bruit d’attaque et la surface exposée. La directive Port dans /etc/ssh/sshd_config permet d’écarter les scans qui ciblent systématiquement le port 22.
Configurer Protocol 2 est impératif pour bénéficier des algorithmes modernes et du chiffrement renforcé. Après modification, il faut recharger le service pour appliquer les changements sans couper les sessions actives.
Tableau des directives principales pour le port et le protocole :
Directive
Objectif
Recommandation
Port
Réduire le bruit d’attaque ciblant le port 22
Choisir un port non réservé, par exemple 2222 ou 7256
Protocol
Forcer la version sécurisée du protocole
Protocol 2
ListenAddress
Restreindre les interfaces d’écoute
Adresse interne ou management VLAN uniquement
HostKeyAlgorithms
Limiter aux algorithmes robustes
Préférer les courbes ED25519 et RSA 3072+
- Port SSH recommandé : hors plage 0-1023 pour éviter conflits système
- Vérification du port : utiliser la commande ss -lntp | grep ssh
- Recharge sans coupure : systemctl reload sshd pour préserver les sessions
Chiffrement et clés d’hôte dans le répertoire /etc/ssh
Ce bloc montre comment le chiffrement s’organise et pourquoi les fichiers d’hôtes sont critiques à vérifier. Les fichiers ssh_host_* attestent l’identité du serveur durant l’authentification initiale des clients.
La rotation des clés d’hôte doit être planifiée et documentée pour éviter des interruptions de service involontaires. Selon OpenSSH, privilégier ED25519 assure un bon compromis entre sécurité et performance.
« J’ai changé le port et réduit immédiatement le trafic malveillant observé sur mes logs »
Alex N.
Cette mesure simple augmente la friction pour les attaquants sans complexifier l’accès des administrateurs. Enchaînement vers le contrôle fin des accès et la gestion des utilisateurs.
Pour restreindre l’accès, contrôle des utilisateurs, groupes et accès root SSH
Listes blanches avec AllowUsers et AllowGroups
Pour limiter les comptes autorisés, préférez une politique de liste blanche plutôt qu’une liste noire. La directive AllowGroups facilite l’administration en entreprise et réduit les erreurs humaines.
Créer un groupe dédié et y ajouter les opérateurs permet de gérer les accès par simple ajout ou retrait de membres. Selon Debian, cette méthode est plus scalable que la modification manuelle de la configuration SSH.
Groupes d’accès autorisés :
- Admin SSH dédié : groupe pour les opérateurs systèmes
- Accès support temporaire : groupe pour interventions limitées
- Maintenance automatisée : groupe pour tâches cron et sauvegardes
« J’ajoute et je retire des membres du groupe ssh_allowed sans toucher au sshd_config »
Marine N.
Interdire l’accès root et politiques d’authentification clés
Empêcher l’accès direct de l’utilisateur root est une règle de base pour minimiser l’impact d’un compte compromis. La directive PermitRootLogin no doit être la valeur par défaut en production.
Favorisez l’authentification par clé plutôt que les mots de passe pour toutes les connexions privilégiées. Selon OpenSSH, la combinaison clé publique et passphrase assure une protection robuste face aux tentatives de brute force.
Directive
Effet
Exemple
AllowUsers
Liste blanche d’utilisateurs SSH
AllowUsers mickael florian
AllowGroups
Liste blanche par groupe
AllowGroups ssh_allowed
PermitRootLogin
Blocage de la connexion directe root
PermitRootLogin no
PasswordAuthentication
Désactivation mot de passe interactif
PasswordAuthentication no
« Après avoir activé les clés publiques, les incidents de connexion ont chuté »
Paul N.
Bloquer root et forcer les clés rend l’accès plus traçable et sûr pour l’équipe. Ce point mène naturellement à la surveillance opérationnelle et aux réponses automatisées.
Ensuite, surveillance des logs, bannière légale et réponses automatiques
Analyse des journaux SSH et détection des anomalies
L’analyse régulière des fichiers sous /var/log/auth.log fournit des indicateurs précoces d’attaque ou d’usurpation. Selon Fail2ban, repérer des séries de Failed password permet d’automatiser le blocage d’IP malveillantes.
Interpréter les messages Invalid user et Failed password aide à distinguer reconnaissance active et attaque ciblée. Les PID et horodatages facilitent la corrélation des événements et la réponse appropriée.
- Surveiller Accepted password et session opened pour traçabilité complète
- Filtrer Invalid user pour détecter les tentatives de reconnaissance
- Activer alertes pour pics anormaux d’échecs d’authentification
Automatisation des réponses avec fail2ban et bannières MOTD
Automatiser le blocage d’adresses IP après un seuil d’échecs réduit l’impact des attaques par force brute. Selon fail2ban, l’association de journaux et de règles dynamiques protège efficacement les services exposés.
Personnaliser /etc/motd permet d’afficher un avertissement légal et d’améliorer la conformité des accès. Ce message, associé à PrintLastLog, renforce la traçabilité pour les administrateurs lors de chaque connexion.
- Configurer fail2ban pour surveiller /var/log/auth.log et bannir automatiquement
- Mettre un message MOTD clair pour rappeler les règles d’accès et surveillance
- Prévoir des sauvegardes des clés et plan de rotation régulier
« L’alerte automatique a permis d’identifier une campagne de brute force ciblée sur notre zone publique »
Claire N.
