Aller au contenu principal
Retour au blog
Technique 4 min 27 avril 2026

J'ai sécurisé mon SSH en moins de 10 minutes. Voici exactement ce que j'ai fait.

SSH Linux Hardening SysAdmin DevOps
Partager LinkedIn X / Twitter

SSH reste l'une des principales portes d'entrée des attaques — et beaucoup de serveurs sont encore mal configurés.


En moins de 10 minutes, j'ai appliqué une checklist simple et efficace. Voici exactement ce que j'ai fait.

❌ Les erreurs que je vois le plus souvent

Root login activé

Cible prioritaire des attaquants

Auth par mot de passe

Brute force facilité sans limite

Port 22 exposé

Scanné en continu par des bots

Aucun mécanisme de blocage

Tentatives d'attaque illimitées

Accès non restreint

Surface d'attaque maximale

💾1. Sauvegarder la configuration

👉 Toujours. Avant toute modification.

  • cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
  • Vérifier que la sauvegarde est lisible
  • Conserver une session ouverte pendant les tests

🚫2. Désactiver l'accès root

👉 PermitRootLogin no

  • Modifier /etc/ssh/sshd_config
  • Créer un utilisateur dédié avec sudo
  • Vérifier que le compte non-root fonctionne

🔑3. Forcer l'auth par clés SSH

👉 PasswordAuthentication no

  • Générer une paire de clés (ssh-keygen -t ed25519)
  • Déposer la clé publique sur le serveur
  • Désactiver les mots de passe seulement après test

🌐4. Limiter l'exposition réseau

👉 Port 2222 (ou autre) + AllowUsers

  • Changer le port par défaut (optionnel mais utile)
  • Restreindre l'accès par IP si possible
  • Mettre à jour les règles firewall (ufw / iptables)

👤5. Contrôler les utilisateurs autorisés

👉 AllowUsers monuser

  • Lister explicitement les comptes autorisés
  • Supprimer ou désactiver les comptes inutilisés
  • Utiliser des groupes pour simplifier la gestion

🛡️6. Mettre en place Fail2ban

👉 Bloque les IP après X tentatives

  • apt install fail2ban (Debian/Ubuntu)
  • Configurer jail.local pour SSH
  • Vérifier les logs : fail2ban-client status sshd

7. Tester avant de fermer la session

👉 Ne jamais se lock soi-même.

  • Ouvrir une 2e session de test avant de fermer la 1re
  • Recharger SSH : systemctl reload sshd
  • Vérifier la connexion avec les nouveaux paramètres

🎯 Résultats obtenus

🛡️

Tentatives de brute force fortement réduites

🔒

Accès non autorisé beaucoup plus difficile

📉

Surface d'attaque significativement diminuée

🧠 À retenir

La sécurité ne repose pas sur :

❌ des outils « magiques »

❌ de la chance

❌ des actions ponctuelles

Elle repose sur :

✔ des procédures claires

✔ des bonnes pratiques appliquées

✔ de la discipline dans le temps

Et vous — avez-vous déjà audité la configuration SSH de vos serveurs ? Quelle est la première mesure que vous appliquez systématiquement ?

Partager LinkedIn X / Twitter

Besoin d'un accompagnement personnalisé ?

NagaShield Security vous aide à mettre en place ces mesures de manière concrète, adaptée à votre structure et votre budget.

Demander un diagnostic gratuit
🛡️

Besoin d'aide sur ce sujet ?

Pentest & Audit Technique