Sécuriser vos connexions SSH : clés, ports, Fail2ban, bonnes pratiques

Le SSH, porte d’entrée de votre serveur, mérite une protection de forteresse. Passer des mots de passe aux clés, durcir la configuration et automatiser la défense : voici comment réduire à néant les attaques par force brute et les scans automatisés.

Un Virtual Private Server mal protégé est scanné en quelques minutes après son exposition. Les bots testent des milliers de combinaisons sur le port 22, exploitent des clés faibles ou des versions d’OpenSSH obsolètes. Heureusement, la majorité des risques se neutralisent en cinq minutes de configuration soignée.

Découvrez ci‑dessous les étapes clés – classées de la plus rapide à la plus avancée – pour transformer votre connexion SSH en bunker numérique.

1. Passer à l’authentification par clé
   Générer une clé Ed25519 : ssh-keygen -t ed25519 -C "votre_mail". Copiez‑la via ssh-copy-id user@serveur. Dans /etc/ssh/sshd_config, forcez ensuite PasswordAuthentication no.
2. Désactiver la connexion root directe
   Ajoutez un utilisateur sudo (adduser dev && usermod -aG sudo dev) puis PermitRootLogin no. Toute élévation passe par sudo ; chaque action est loguée.
3. Changer le port par défaut
   Éloigner SSH du port 22 ne remplace pas la sécurité, mais coupe 90 % du bruit. Exemple : Port 2224 puis ouvrir ce port dans le pare‑feu.
4. Activer et restreindre le pare‑feu
   Avec UFW : ufw allow 2224/tcp  |  ufw enable. Avec firewalld : firewall-cmd --permanent --add-port=2224/tcp.
5. Installer Fail2ban
   apt install fail2ban ou dnf install fail2ban. Créez /etc/fail2ban/jail.local :

   [sshd]
   enabled = true
   port    = 2224
   maxretry = 5
   bantime  = 1h
   

   Fail2ban lit les logs, bannit l’IP après maxretry tentatives et débanne automatiquement.
6. Restreindre les utilisateurs et les groupes
   Dans sshd_config : AllowGroups sshusers ou AllowUsers [email protected].*. Un simple groupe dédié limite la surface d’attaque.
7. Désactiver les algorithmes faibles
   KexAlgorithms, Ciphers et MACs peuvent être durcis ; gardez uniquement les suites modernes (chacha20‑poly1305, aes‑gcm, etc.).
8. Activer l’authentification à deux facteurs (Optionnel)
   PAM + Google Authenticator ou Duo MFA ajoutent un code TOTP après la clé SSH, idéal pour les accès critiques.
9. Surveiller les logs et recevoir des alertes
   Centralisez /var/log/auth.log dans Grafana Loki ou Graylog ; configurez des alertes sur un pic de connexions échouées.
10. Automatiser les mises à jour OpenSSH
    Activez unattended-upgrades ou un playbook Ansible dédié ; les failles CVE se corrigent parfois en quelques heures, ne prenez pas de retard.

Mémo express : clé Ed25519 + port custom + Fail2ban + pare‑feu = 95 % des attaques bloquées. Les 5 % restants se gèrent par la vigilance (logs, MàJ, MFA).

« Un service SSH bien durci est silencieux : aucun log d’échec, aucune alerte, seulement des connexions légitimes. »

Mathias PAJON

En appliquant ces bonnes pratiques, vous transformez votre serveur en cible peu attrayante pour les attaquants et gagnez un temps précieux en maintenance. Prenez quelques minutes pour auditer votre configuration : chaque ligne de sshd_config bien pensée est un pas supplémentaire vers un hébergement fiable et résilient.