Audit SSH express : 12 tests à lancer avant de dormir

On a tous vécu le truc. Tu déploies un serveur, tu ouvres l’accès SSH, tu configures deux trois trucs, tu te dis « ok, c’est bon, j’ai la main ». Et puis tu passes à autre chose.

Sauf que… SSH, c’est la porte d’entrée. La porte d’entrée du serveur, mais aussi de ta prod, de tes bases, de tes clients, de ton temps, de tes nerfs. Donc avant d’aller dormir (littéralement), je te propose un mini rituel. Un audit SSH express, 12 tests simples, concrets, que tu peux lancer en 10 à 20 minutes.

Le but n’est pas d’être parano. C’est d’éviter les erreurs bêtes, les accès trop larges, les services exposés pour rien, et le « on verra demain ». Non. On vérifie maintenant. Et on dort mieux.

Notes : les commandes ci dessous sont pensées pour Linux côté serveur, et un poste client Linux ou macOS. Adapte si tu es sur Windows (PowerShell, PuTTY, etc.). Et évidemment, fais ça avec un compte qui a le droit de lire la conf SSH.

Pré requis rapide

Avant de lancer les tests, garde ces trois infos sous la main :

• IP ou nom de domaine du serveur
• utilisateur SSH
• port SSH (par défaut 22)

Je vais utiliser des variables :

• HOST=monserveur.tld
• USER=samyn
• PORT=22

Cependant, il est crucial de garder à l'esprit que la sécurité SSH ne doit pas être prise à la légère. En effet, une mauvaise configuration peut mener à des erreurs fatales de sécurité qui pourraient compromettre l'intégrité de ton serveur et de tes données. Il est donc recommandé de s'informer sur ces erreurs et comment les éviter.

De plus, avec l'essor de l'IA dans le développement web et logiciel, il est devenu courant d'utiliser des outils d'IA pour remplacer une partie du travail humain. Cela dit, il est essentiel de comprendre que même si ces outils peuvent améliorer l'efficacité et réduire le temps nécessaire pour certaines tâches, ils ne remplacent pas la nécessité d'une bonne sécurité.

Et enfin, dans le monde numérique actuel où le contenu est roi, il est important de maîtriser l'art du content repurposing. Cela signifie que même si tu as mis en place une bonne sécurité pour ton serveur et que tu utilises des outils d'IA pour faciliter ton travail, il est toujours possible que certaines informations sensibles soient exposées ou utilisées à des fins non prévues.

1) Vérifier que tu n’exposes pas SSH « partout » sans le savoir

Sur le serveur :

bash ss -tulpn | grep -E '(:22|:2222)\s'

Ou si ton port est custom :

bash ss -tulpn | grep ":$PORT"

Ce que tu veux voir : LISTEN sur 0.0.0.0 ou :: si c’est volontaire. Si tu pensais que SSH était limité à une IP interne et que tu vois 0.0.0.0, tu viens peut être de découvrir un problème.

Astuce : si tu es derrière un firewall cloud (Security Group, firewall OVH, etc.), vérifie aussi là bas. Les surprises arrivent souvent à ce niveau.

---

2) Tester la connexion en mode verbeux pour repérer les failles évidentes

Depuis ton client :

bash ssh -vvv -p $PORT $USER@$HOST

Regarde :

• quelle méthode d’authentification est proposée en premier
• si le serveur accepte encore le mot de passe
• si tu vois des algos bizarres (anciens ciphers, vieux KEX)

Tu n’as pas besoin d’être cryptographe. Si tu vois des lignes qui crient « legacy », tu notes.

---

3) Vérifier l’empreinte de clé hôte (et éviter le MITM tranquille)

Toujours depuis ton client :

bash ssh-keyscan -p $PORT -H $HOST

Compare avec ce que le serveur annonce :

Sur le serveur :

bash ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub 2>/dev/null

Ce que tu veux : utiliser ed25519 en priorité. RSA peut rester, mais éviter les configs antiques.

Si tu es sur une infra pro, tu peux stocker ces empreintes dans ton gestionnaire de doc interne. Perso, je garde ce genre de checklists sur mon espace et mes ressources sur Le Blog Tech Pro de Samyn-Antoy ABASSE, parce que ça évite de tout réinventer à chaque mission.

Pour approfondir tes connaissances, il existe plusieurs domaines où une maîtrise accrue pourrait te donner un avantage considérable. Par exemple, maîtriser Linux pourrait ouvrir de nombreuses portes dans le domaine tech. De plus, comprendre les nuances entre Linux et Windows pourrait s'avérer bénéfique dans certaines situations professionnelles. Enfin, si tu es intéressé par des stratégies innovantes pour augmenter ta visibilité en ligne ou atteindre tes objectifs professionnels, je te recommande de lire sur le sujet du growth hacking sur LinkedIn, car cela pourrait te fournir des outils précieux pour optimiser ta présence digitale

4) Vérifier si le login root est désactivé (ou au moins verrouillé)

Sur le serveur :

bash sshd -T | grep -i permitrootlogin

Tu veux idéalement :

• permitrootlogin no

Ou au minimum :

• permitrootlogin prohibit-password (clé uniquement)

Ensuite, teste réellement :

bash ssh -p $PORT root@$HOST

Même si tu sais que ça ne doit pas passer. Ce test est bête, mais il attrape des erreurs de conf, des overrides, ou des includes surprises.

---

5) Vérifier si l’authentification par mot de passe est coupée

Sur le serveur :

bash sshd -T | grep -i passwordauthentication

Objectif :

• passwordauthentication no

Et côté client, tu peux forcer un test :

bash ssh -p $PORT -o PreferredAuthentications=password -o PubkeyAuthentication=no $USER@$HOST

Résultat attendu : refus. Si ça passe… bon. Tu sais ce qu’il te reste à faire.

---

6) Vérifier que tes clés SSH ne sont pas « faibles » ou trop ouvertes

Sur ton poste (pour vérifier ta clé) :

bash ssh-keygen -lf ~/.ssh/id_ed25519.pub

Ensuite, côté serveur, audit rapide du fichier :

bash ls -la ~/.ssh ls -la ~/.ssh/authorized_keys

Permissions attendues, en gros :

• ~/.ssh en 700
• authorized_keys en 600

Tu peux corriger :

bash chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys

Et si tu veux aller un peu plus loin sans te prendre la tête : dans authorized_keys, tu peux restreindre une clé avec des options (from=, command=, no-port-forwarding, etc.). Pas obligatoire pour ce rituel du soir, mais c’est un vrai plus en environnement sensible.

Pour une approche plus détaillée sur la sécurisation de votre SSH, je vous recommande cette checklist de hardening SSH. Si vous envisagez de devenir consultant Linux en freelance, cet article sur devenir consultant Linux en freelance pourrait également vous intéresser.

7) Vérifier les tentatives de brute force dans les logs

Sur Debian/Ubuntu :

bash sudo tail -n 200 /var/log/auth.log

Sur RHEL/CentOS/Alma :

bash sudo tail -n 200 /var/log/secure

Filtre rapide :

bash sudo grep -i "failed password" /var/log/auth.log | tail -n 50 sudo grep -i "invalid user" /var/log/auth.log | tail -n 50

Tu peux aussi regarder les IP qui reviennent :

bash sudo grep -i "failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head

Si tu vois des tentatives non stop, ce n’est pas forcément « grave » (internet est comme ça), mais ça confirme que ton SSH est bien visible et qu’il faut être strict sur les méthodes d’auth.

---

8) Vérifier Fail2ban (ou un équivalent) et ses jails SSH

Si tu utilises Fail2ban :

bash sudo fail2ban-client status sudo fail2ban-client status sshd

Tu veux voir :

• jail sshd actif
• des IP bannies (selon trafic)
• des paramètres cohérents : bantime, findtime, maxretry

Si tu n’as pas Fail2ban : ce n’est pas obligatoire, surtout si ton firewall est bien verrouillé et que tu es en clé uniquement. Mais en pratique, c’est un bon amortisseur.

Pour aller plus loin dans la sécurité de ton serveur, tu pourrais envisager d'appliquer certaines stratégies de growth hacking, qui peuvent inclure des mesures supplémentaires pour renforcer la sécurité.

9) Vérifier la conf effective de sshd (pas juste ton fichier)

C’est un point hyper sous estimé. Tu changes /etc/ssh/sshd_config, tu penses que c’est bon. Puis un include dans /etc/ssh/sshd_config.d/ écrase tout, ou l’inverse.

Commande reine :

bash sudo sshd -T | sort

Ensuite, filtre ce qui nous intéresse :

bash sudo sshd -T | egrep -i 'port|listenaddress|permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication|x11forwarding|allowusers|allowgroups|loglevel|clientaliveinterval|clientalivecountmax'

Deux réglages utiles pour éviter les sessions fantômes :

• clientaliveinterval 300
• clientalivecountmax 2

Pas magique, mais ça nettoie.

---

10) Vérifier le forwarding et les options « confort » dangereuses

Toujours via sshd -T :

bash sudo sshd -T | egrep -i 'x11forwarding|allowtcpforwarding|permittty|permitemptypasswords|gatewayports|permituserenvironment'

Recommandation simple pour un serveur classique :

• x11forwarding no
• allowtcpforwarding no si tu n’en as pas besoin (sinon, laisse yes mais assume)
• permitemptypasswords no

Le port forwarding est super utile, oui. Mais quand c’est activé « par défaut » sur un serveur exposé, sans besoin réel, c’est juste une surface d’attaque en plus.

---

11) Scanner le port SSH depuis l’extérieur (comme un attaquant ferait)

Depuis une autre machine (ou ton laptop via un réseau différent) :

bash nmap -sV -p $PORT $HOST

Tu regardes :

• si le port est bien celui attendu
• si la bannière révèle des infos
• si tu as d’autres ports ouverts que tu avais oubliés (tant qu’à faire, tu peux lancer un -p- plus tard)

Pour un check express, ça suffit.

---

Si tu es intéressé par des carrières dans l'administration système ou la cybersécurité, il peut être judicieux de considérer certaines des top certifications Linux disponibles. Par ailleurs, pour ceux qui envisagent une transition vers des rôles axés sur le marketing numérique ou la croissance des entreprises, explorer les stratégies de growth hacking pourrait offrir des perspectives intéressantes. Enfin, si tu te demandes quel système d'exploitation choisir entre Linux et Windows, cela dépendra largement de tes besoins spécifiques et de tes préférences personnelles.

12) Lancer un audit automatique rapide avec ssh-audit

ssh-audit est un outil simple qui te dit : algos ok, algos faibles, recommandations. Sans blabla.

Installation (selon ton OS, sinon via pip) :

bash pipx install ssh-audit

python3 -m pip install --user ssh-audit

Puis :

bash ssh-audit -p $PORT $HOST

Tu lis surtout :

• KEX
• host key algorithms
• ciphers
• MACs

Tu n’es pas obligé de corriger tout ce qu’il dit. Mais si tu vois des « fail » ou des « warn » sur des trucs vraiment anciens, tu planifies une amélioration.

---

Si tu veux la version ultra compacte, celle que tu colles dans un bloc notes.

• SSH écoute sur le bon port, sur la bonne interface
• root login : désactivé
• password auth : désactivée
• clé ed25519 utilisée, permissions .ssh propres
• logs : pas d’anomalies évidentes
• Fail2ban (ou firewall) : ok
• conf effective sshd -T : vérifiée
• forwarding : uniquement si besoin
• scan externe nmap : ok
• ssh-audit : rien de critique

---

Deux trois remarques (vraies) avant de terminer

1. Changer le port SSH n’est pas une sécurité en soi. Ça baisse juste le bruit. Le vrai bouclier, c’est clés uniquement, root off, et firewall.
2. Le meilleur SSH, c’est parfois… pas d’SSH exposé. Tailscale, WireGuard, bastion, jump host, etc. Mais je sais, dans la vraie vie on doit souvent faire simple.
3. Le plus dangereux, ce n’est pas « l’attaque sophistiquée ». C’est le serveur oublié, l’accès partagé, la clé copiée partout, le stagiaire qui a mis PasswordAuthentication yes pour dépanner et qui est parti dormir.

Si tu veux explorer davantage sur les meilleures pratiques en matière de sécurité SSH et comment optimiser votre utilisation de cette technologie pour une meilleure liberté numérique, je peux aussi te faire une version « script » de cet audit (un seul script bash qui sort en vert ou rouge), et tu l’ajoutes à ton rituel. Tu peux me le dire via le site Le Blog Tech Pro de Samyn-Antoy ABASSE où je poste souvent des checklists SysAdmin et des workflows productivité qui vont bien avec ce genre de routine.

---

Ressources utiles (rapides)

• Fichier principal : /etc/ssh/sshd_config
• Includes possibles : /etc/ssh/sshd_config.d/*.conf
• Tester la conf : sshd -t
• Voir la conf effective : sshd -T
• Logs : /var/log/auth.log ou /var/log/secure

---

Conclusion

Cet audit SSH express, c’est juste 12 tests. Pas une certification sécurité. Mais c’est exactement le genre de routine qui évite 80 % des galères.

Tu lances, tu vois si quelque chose cloche, tu corriges un point ou deux. Et ensuite seulement tu vas dormir. Parce que oui, demain tu as déjà assez de problèmes à résoudre. Autant ne pas en laisser un ouvert sur le port 22.

Pour ceux qui envisagent d'approfondir leurs connaissances en matière de sécurité SSH et de certifications, ces ressources peuvent être utiles. Par exemple, cet article sur la certification Linux 2026 pourrait vous fournir des informations précieuses. Si vous êtes intéressé par l'automatisation DevOps, ce lien est un bon point de départ.

De plus, pour ceux qui cherchent à améliorer leur stratégie de croissance dans le domaine numérique, cet article sur le growth hacking authentique pourrait être très bénéfique. Enfin, pour les freelances souhaitant devenir experts en Linux, voici une roadmap utile.

Questions fréquemment posées

Pourquoi est-il crucial de sécuriser l'accès SSH sur un serveur ?

SSH est la porte d'entrée principale vers ton serveur, ta production, tes bases de données, et même ta tranquillité d'esprit. Une mauvaise configuration peut exposer ton système à des risques importants, compromettant la sécurité de tes données et la stabilité de ton infrastructure.

Quels sont les prérequis avant de réaliser un audit SSH express ?

Avant de lancer l'audit, il faut avoir sous la main l'adresse IP ou le nom de domaine du serveur, le nom d'utilisateur SSH, et le port SSH utilisé (par défaut 22). Ces informations permettront d'adapter les commandes pour vérifier la configuration.

Comment vérifier que le service SSH n'est pas exposé à tout le monde par erreur ?

Sur le serveur, utilise la commande ss -tulpn | grep ":$PORT" pour voir sur quelles adresses IP SSH écoute. Si tu vois LISTEN sur 0.0.0.0 ou ::, cela signifie que SSH est accessible depuis toutes les interfaces réseau, ce qui peut être un risque si ce n'est pas intentionnel. Pense aussi à vérifier les règles du firewall cloud associé.

Comment tester la connexion SSH en mode verbeux pour détecter des failles évidentes ?

Depuis ton poste client Linux ou macOS, lance ssh -vvv -p $PORT $USER@$HOST. Cette commande affiche en détail les étapes d'authentification et les algorithmes utilisés. Tu peux ainsi repérer si le serveur accepte encore l'authentification par mot de passe ou utilise des algorithmes obsolètes.

Pourquoi comparer l'empreinte de clé hôte SSH est important ?

Comparer l'empreinte de clé hôte permet d'éviter les attaques Man-In-The-Middle (MITM). En vérifiant que la clé publique annoncée par le serveur correspond bien à celle attendue, tu t'assures que tu te connectes au bon serveur et non à un imposteur.

Est-ce suffisant de faire un audit express pour garantir une sécurité totale ?

L'audit express est un bon point de départ pour éviter les erreurs courantes et améliorer rapidement la sécurité SSH. Cependant, il ne remplace pas une politique globale de sécurité ni une veille régulière sur les nouvelles vulnérabilités et bonnes pratiques.