Audit SSH : méthode concrète pour contrôler et durcir l’accès à tes serveurs Linux

Quand une PME ou un éditeur SaaS demande un audit SSH, le vrai besoin n’est pas de lancer un scan gadget. Il s’agit de savoir si les accès d’administration à distance sont trop permissifs, mal journalisés, exposés à des algorithmes faibles ou encore dépendants de comptes hérités dont personne n’ose supprimer les clés. Sur une infrastructure Linux, SSH est souvent le point d’entrée critique des opérations courantes. C’est aussi l’un des chemins les plus fréquents vers un incident évitable. Un audit bien mené permet d’objectiver le risque, d’aligner l’équipe sur des priorités simples et de réduire l’exposition sans casser la production.

Réponse rapide

Un audit SSH consiste à vérifier quatre blocs, la configuration sshd, les algorithmes et versions exposés, les comptes et clés réellement autorisés, puis la traçabilité des connexions. La méthode la plus efficace combine un scan outillé avec ssh-audit, une revue des fichiers de configuration, un contrôle des accès humains et un plan de remédiation priorisé.

Pourquoi auditer SSH avant de parler durcissement

Beaucoup d’équipes passent directement au hardening, désactivation du login root, changement de port, MFA, fail2ban, sans mesurer l’état réel de départ. C’est une erreur classique. Un audit SSH sert d’abord à créer une photographie fiable. Sans cette base, tu risques de corriger un détail visible tout en laissant en place des comptes techniques oubliés, des clés non tracées, des accès bastion incomplets ou des algorithmes obsolètes toujours actifs.

Dans un contexte B2B, l’audit SSH répond aussi à une exigence de gouvernance. Un DSI, un CTO ou un RSSI veut savoir si l’accès d’administration respecte les bonnes pratiques minimales, si les prestataires externes sont correctement isolés, et si un incident pourra être reconstruit grâce aux journaux. Le sujet dépasse largement le simple réglage d’sshd_config.

Le bon périmètre pour un audit SSH exploitable

Pour être utile, l’audit doit couvrir l’exposition externe, l’exposition interne, les comptes humains, les comptes de service, les jump hosts éventuels et la journalisation. Sur une petite infra, cela peut tenir sur quelques VM. Sur un parc plus large, il faut raisonner par classes de serveurs, production, préproduction, administration centralisée, outillage CI/CD, sauvegardes, supervision, VPN et bastions.

Méthode d’audit SSH en 6 étapes

Étape 1, cartographier l’exposition. Commence par lister les machines qui acceptent SSH et leur contexte d’accès. Une VM exposée directement à Internet ne porte pas le même niveau de risque qu’un nœud joignable uniquement depuis un bastion. Ce travail conditionne toute la suite.

Étape 2, récupérer la configuration effective. Lire uniquement /etc/ssh/sshd_config ne suffit pas toujours, surtout si tu utilises des fichiers inclus. La commande ci-dessous est plus fiable parce qu’elle montre le rendu effectif de nombreux paramètres.

sudo sshd -T
sudo sshd -T | egrep 'permitrootlogin|passwordauthentication|pubkeyauthentication|kexalgorithms|ciphers|macs|allowusers|allowgroups'

Étape 3, auditer les algorithmes et la version exposée. C’est là que ssh-audit apporte de la valeur. L’outil identifie rapidement les ciphers trop faibles, les algorithmes dépréciés ou les réglages trop ouverts.

Comment utiliser ssh-audit dans un vrai audit SSH

L’outil ssh-audit est excellent pour objectiver la partie protocole. Il ne remplace pas la revue des accès, mais il accélère énormément la lecture technique d’une surface SSH.

python3 -m pip install --user ssh-audit
~/.local/bin/ssh-audit serveur.exemple.tld
~/.local/bin/ssh-audit -p 2222 10.0.10.15

Sur un parc d’hôtes, tu peux industrialiser le contrôle. Le point important n’est pas seulement le rapport brut, mais la capacité à traduire les résultats en décisions opérationnelles. Un algorithme faible sur une VM de préproduction isolée n’a pas la même urgence qu’un mot de passe encore autorisé sur un bastion exposé.

Voici un exemple de contrôles complémentaires qui donnent du sens aux résultats de l’outil.

# Comptes avec shell interactif
getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {print $1":"$7}'

# Présence de clés autorisées
sudo find /home /root -name authorized_keys -type f -print

# Dernières connexions
last -ai | head -20
journalctl -u ssh --since "-7 days"

Si tu veux aller plus loin, relie l’audit SSH à ton socle de maintenance Linux, à ton contrôle des changements et à ton runbook d’incident. Sur linux-man.fr, deux lectures complémentaires sont utiles, la checklist de maintenance serveurs Linux et le guide de hardening SSH avec Ansible. Le premier t’aide à cadrer la gouvernance, le second à industrialiser les correctifs une fois l’audit terminé.

Construire un plan de remédiation utile au métier

Un bon audit SSH ne s’arrête pas au constat. Il doit déboucher sur un plan d’action compréhensible par l’équipe technique et arbitrable par le management. Je recommande trois niveaux de priorité.

Priorité 1, réduire l’exposition immédiate. Fermer les accès Internet inutiles, restreindre par IP ou VPN, désactiver l’authentification par mot de passe si le contexte le permet, supprimer les comptes inactifs et vérifier l’absence de clés orphelines.

Priorité 2, durcir la configuration. Mettre à jour OpenSSH, retirer les algorithmes faibles, revoir PermitRootLogin, imposer des groupes d’accès dédiés, et standardiser les paramètres sur les différentes classes de serveurs.

Priorité 3, renforcer la traçabilité. Activer une journalisation lisible, centraliser les logs, corréler les connexions anormales et documenter qui possède quelles clés. C’est souvent ce bloc qui manque alors qu’il change tout lors d’une enquête après incident.

Pour les environnements qui grandissent vite, j’aime aussi relier l’audit SSH à une revue plus large de gouvernance et d’infogérance. Si ton équipe n’a pas le temps de suivre la dette d’accès, de maintenance et de journalisation, un accompagnement récurrent évite que le prochain audit ne reproduise les mêmes écarts. Cette logique rejoint aussi l’approche décrite dans l’article sur l’industrialisation d’une infra Linux avec Ansible.

Erreurs courantes pendant un audit SSH

FAQ sur l’audit SSH

Conclusion

Un audit SSH bien mené réduit le risque opérationnel, améliore la traçabilité et prépare un durcissement cohérent. C’est un levier concret pour les PME qui veulent reprendre le contrôle de leurs accès d’administration sans lancer un chantier trop lourd. Si tu as plusieurs serveurs, des prestataires externes ou des exceptions historiques difficiles à assainir, mieux vaut cadrer la démarche avec une méthode claire plutôt que corriger dans l’urgence au fil des alertes.