SSH reste le protocole prioritaire pour l’administration distante et les transferts sécurisés en 2025. Ce guide pédagogique propose des pratiques claires pour durcir un serveur Linux accessible en SSH.
Il couvre l’authentification par clé, les contrôles d’accès, la surveillance et les outils complémentaires. Les points clés suivants éclairent rapidement les protections à prioriser avant toute configuration.
A retenir :
- Authentification par clé publique protection contre attaques par force brute
- Désactivation de root accès direct réduction de la surface d’attaque
- Pare-feu et filtrage UFW Netfilter Firewalld limitation des accès réseau
- Surveillance active logs Auditd fail2ban intégrité et détection rapide
Configurer OpenSSH : durcir le serveur SSH sur Linux
Après avoir priorisé les protections, la configuration d’OpenSSH constitue l’étape technique primordiale pour sécuriser un serveur. Selon OpenSSH, plusieurs options de sshd_config permettent de réduire immédiatement la surface d’exposition.
Mesure
Rôle
Complexité
Priorité
Auth par clés
Remplacer mots de passe
Faible
Élevée
PermitRootLogin no
Bloquer accès root direct
Faible
Élevée
Chiffrement modernisé
Confidentialité et intégrité
Moyenne
Élevée
MFA
Double facteur d’authentification
Moyenne
Moyenne
Quelques réglages précisés ici accélèrent la mise en œuvre et limitent les erreurs opérationnelles. Ces exemples facilitent le passage aux sections pratiques qui suivent.
Mesures prioritaires serveur :
- Générer paire ed25519 et protéger par phrase de passe
- Ajouter la clé publique dans ~/.ssh/authorized_keys via ssh-copy-id
- Mettre PermitRootLogin no et PasswordAuthentication no
- Restreindre les utilisateurs via AllowUsers ou AllowGroups
Authentification par clé publique : génération et gestion de clés
Ce point détaille la génération et la protection des paires de clés, cruciales pour OpenSSH et l’accès sans mot de passe. Selon NIST, les phrases de passe longues et la protection des clés sont des éléments essentiels pour la robustesse de l’authentification.
Bonnes pratiques clés SSH :
- Utiliser ed25519 ou RSA 4096 selon compatibilité
- Protéger la clé privée par une phrase d’au moins quatorze caractères
- Stocker clés avec chmod 700 sur ~/.ssh et chmod 600 sur fichiers
- Envisager HSM ou tokens pour organisations critiques
« J’ai migré trois serveurs vers l’authentification par clé en moins d’une semaine et constaté moins d’incidents. »
Alice B.
La gestion active des phrases et l’emploi d’un agent SSH réduisent les frictions pour les administrateurs. Ces méthodes ouvrent ensuite la nécessité de vérifier les empreintes et les fichiers known_hosts.
Gestion des known_hosts et vérification des empreintes
La maintenance du fichier known_hosts protège contre les attaques de type man-in-the-middle et doit être intégrée aux procédures. La vérification manuelle et automatisée des empreintes évite les mauvaises surprises lors des premiers accès.
Action
But
Outil
Vérifier empreinte serveur
Détecter changement de clé
ssh-keygen -lf
Script d’inventaire
Inventorier clés connues
ssh-keyscan
Provisioning central
Déploiement reproductible
Ansible/Chef
Rotation régulière
Limiter compromissions
Procédures internes
Vérifications clés SSH :
- Contrôler empreintes avant ajout dans known_hosts
- Automatiser la collecte avec ssh-keyscan pour inventaire
- Utiliser CM pour déployer authorized_keys de façon centralisée
- Planifier rotation périodique des clefs et révocation
La maîtrise des clés prépare le serveur au durcissement réseau et à la surveillance centralisée. L’étape suivante porte sur les pare-feu, les listes d’accès et la réduction du bruit d’attaque.
Contrôles d’accès réseau et pare-feu pour SSH en production
À la suite du durcissement du service, limiter l’accès réseau demeure une couche essentielle pour réduire l’exposition. Selon ANSSI, l’usage combiné de pare-feu et de filtres réseau renforce significativement la posture de sécurité.
Outil
Rôle
Usage typique
UFW
Interface simple de pare-feu
Blocage/autorisation de plages IP
Netfilter
Filtrage bas niveau
Politiques complexes et NAT
Firewalld
Gestion de zones dynamiques
Scénarios cloud et conteneurs
SSH sur port non standard
Réduction du balayage automatisé
Complément, non substitution
Contrôles réseau recommandés :
- Autoriser SSH uniquement depuis sous-réseaux approuvés
- Mettre en place bastion/jump hosts pour centraliser accès
- Modifier port par défaut pour réduire le bruit
- Coupler pare-feu avec fail2ban pour réponse automatisée
Limitation par IP et bastion SSH pour accès restreint
Ce focus explique l’utilisation de bastions et de listes d’accès pour centraliser et tracer les connexions SSH. La création d’un bastion réduit la nécessité d’exposer plusieurs serveurs au réseau public et facilite l’audit.
Actions pour bastion :
- Installer serveur bastion avec accès journalisé obligatoire
- Forcer authentification par clé et MFA sur le bastion
- Limiter utilisateurs et obligations d’horodatage
- Archiver sessions pour revue après incidents
« Le bastion central a simplifié l’audit des connexions et réduit la surface d’attaque de l’équipe. »
Clara N.
Après cette mise en place, l’automatisation des blocages complète la défense réseau et limite les tentatives massives. Le point suivant couvre précisément l’usage de fail2ban et la surveillance active des journaux.
Mise en place de fail2ban et surveillance des tentatives
Cette section décrit comment fail2ban et la centralisation des logs améliorent la réactivité face aux attaques. Selon NIST et les bonnes pratiques, la détection précoce permet de réduire durablement l’impact des attaques automatisées.
Actions prévention brute :
- Configurer fail2ban pour bannir IP après plusieurs échecs
- Centraliser logs SSH avec rsyslog puis corréler via SIEM
- Mettre enclosure d’alertes pour blocage manuel rapide
- Surveiller timestamps et sources pour détection d’attaques distribuées
« Depuis l’activation de fail2ban, nos logs montrent des tentatives bloquées toutes les nuits. »
Marc D.
La surveillance active s’articule naturellement avec des audits réguliers et l’analyse post-incident. L’étape suivante évoque la journalisation avancée, les audits et les outils complémentaires à déployer.
Surveillance, audit et remédiation : Auditd, Lynis et outils complémentaires
Suite aux contrôles réseau, les procédures d’audit et d’analyse renforcent la détection et la conformité opérationnelle. Selon des pratiques éprouvées, l’association d’Auditd, Lynis et d’outils antivirus accroît la résilience globale.
Outil
Fonction
Fréquence recommandée
Auditd
Collecte événements système
Continu
Lynis
Scanner durcissement système
Périodique
ClamAV
Analyse signatures et malwares
Selon charge et incidents
SELinux
Confinement des processus
Continu si activé
Outils et contrôles :
- Activer Auditd pour tracer activités sensibles sur SSH
- Lancer Lynis pour audits réguliers et recommandations pratiques
- Déployer SELinux en mode enforcing quand possible
- Scanner périodiquement avec ClamAV et corriger détections
Journalisation centrale et corrélation SIEM
Ce passage explique la centralisation des logs et la corrélation via SIEM pour détecter anomalies et attaques persistantes. L’agrégation améliore la visibilité et facilite la réponse coordonnée aux incidents.
Actions SIEM recommandées :
- Envoyer logs SSH vers solution centrale en temps réel
- Créer règles pour détection d’échecs répétés et comportements anormaux
- Intégrer alertes à procédures de remédiation
- Conserver preuves pour audit et investigation
« Un audit régulier et une hygiène des clés restent essentiels face aux menaces évolutives. »
Jean P.
La revue périodique permet d’ajuster politiques et d’intégrer des certificats automatiques via LetsEncrypt pour services HTTPS associés. Cette pratique complète la posture SSH et facilite la conformité technique.
Révision périodique et durcissement continu
Ce dernier volet présente la méthodologie de maintenance et la vérification continue des contrôles implémentés. Les audits automatisés et manuels garantissent que les règles restent effectives dans le temps.
Checklist durcissement :
- Planifier scans Lynis et analyser résultats par priorité
- Vérifier configurations OpenSSH et appliquer correctifs
- Tester restauration d’accès via comptes administrateurs de secours
- Documenter procédures et former les équipes opérationnelles
Enfin, combiner outils comme Fail2ban, Auditd et scans Lynis fournit une base robuste pour la sécurité continue. Ces éléments forment un socle sur lequel évoluer vers des solutions avancées et intégrées.
