Sur un serveur Linux, SSH est presque toujours le premier point de contact avec le système. C’est aussi, mécaniquement, l’un des services les plus attaqués. Scans automatisés, brute force, tentatives d’authentification par clé volée : un port SSH exposé sur Internet sera testé en permanence.
Dans beaucoup d’environnements, SSH fonctionne « par défaut » : configuration minimale, options héritées, compromis entre sécurité et facilité. Cet article adopte une approche très technique et opérationnelle, comme lors d’un durcissement réel de serveur Linux en production.
Comprendre ce que fait réellement SSH sur le système
Avant de modifier quoi que ce soit, il est essentiel de comprendre comment SSH s’intègre au système.
Le service est généralement géré par systemd :
Le binaire principal est :
Et la configuration repose principalement sur :
Chaque directive dans ce fichier a un impact direct sur :
l’authentification,
les privilèges,
la surface d’attaque exposée.
Identifier l’exposition réseau réelle
Un premier réflexe consiste à vérifier où et comment SSH écoute.
Points à vérifier immédiatement :
écoute sur
0.0.0.0(toutes les interfaces)port par défaut 22
exposition directe à Internet
Un SSH accessible depuis Internet sans filtrage est une cible permanente, même si l’authentification est robuste.
Désactiver l’authentification par mot de passe
L’authentification par mot de passe reste la principale faiblesse de SSH. Même avec un mot de passe fort, elle ouvre la porte au brute force et au credential stuffing.
Dans /etc/ssh/sshd_config :
Redémarrage du service :
À partir de ce moment, seules les clés SSH sont autorisées. C’est une rupture assumée, mais indispensable sur un serveur exposé.
Forcer l’authentification par clé et contrôler les accès
Les clés SSH doivent être :
stockées dans
~/.ssh/authorized_keysprotégées par des permissions strictes
Vérification :
Permissions attendues :
.ssh→700authorized_keys→600
Un fichier accessible en écriture par un tiers équivaut à un accès root déguisé.
Interdire l’accès direct à root
Autoriser la connexion directe de root est une erreur encore fréquente.
Dans la configuration SSH :
Cela force :
une connexion avec un compte nominatif
une élévation contrôlée via
sudo
Résultat : meilleure traçabilité, réduction des attaques automatisées, journalisation exploitable.
Restreindre les utilisateurs autorisés
Un serveur n’a généralement pas vocation à accepter tous les comptes système via SSH.
Toujours dans sshd_config :
AllowUsers admin svc_backup
Ou par groupe :
Cela bloque instantanément :
les comptes système
les utilisateurs oubliés
les comptes créés par des applications tierces
Limiter l’impact d’une compromission
Même avec des clés, une compromission reste possible. Il faut donc limiter les dégâts.
Exemples de durcissement supplémentaires :
Ces options empêchent :
le rebond réseau via SSH
l’utilisation du serveur comme pivot
certains usages détournés post-compromission
Journalisation et détection d’attaques
SSH génère énormément de signaux exploitables.
Consulter les logs :
Rechercher les tentatives échouées :
Un flux constant d’échecs est normal sur un serveur exposé. En revanche :
une réussite inattendue,
un changement de clé,
ou un comportement inhabituel
doivent déclencher une analyse immédiate.
Renforcer SSH avec des contrôles supplémentaires
Sur des environnements sensibles, SSH peut être renforcé avec :
filtrage firewall strict
restriction par IP source
outils anti-brute-force (ex. bannissement temporaire)
Mais ces mécanismes ne compensent jamais une mauvaise configuration SSH. Ils viennent en complément, pas en remplacement.
Conclusion
SSH est un outil robuste, mais il ne pardonne pas l’approximation. Dans la majorité des incidents Linux, l’accès initial passe soit par SSH, soit par un service exposé qui mène ensuite à SSH.
Un SSH correctement durci, c’est :
pas de mot de passe,
pas de root direct,
des utilisateurs explicitement autorisés,
une journalisation exploitée.
Ce n’est pas plus complexe. C’est simplement plus rigoureux.
