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