Administration serveur Linux · Debian & Ubuntu
SSH admin Linux : accès distant et bonnes pratiques
Clés plutôt que mots de passe, durcissement de sshd, fail2ban et pare-feu : sécuriser l’accès SSH d’un serveur Debian ou Ubuntu.
SSH est la porte d’entrée de tout serveur Linux administré à distance : c’est aussi la cible numéro un des robots qui scannent Internet en continu. Sécuriser l’accès SSH n’est pas optionnel dès qu’un serveur est exposé, même sur un port non standard. Ce guide couvre les bonnes pratiques essentielles, de la connexion par clé au blocage automatique des tentatives d’intrusion.
Au programme
- Pourquoi sécuriser SSH en priorité
- Connexion par clé plutôt que mot de passe
- Durcir sshd_config
- Bloquer les tentatives d’intrusion avec fail2ban
- Ouvrir le pare-feu proprement
Pourquoi sécuriser SSH en priorité
Dès qu’un serveur est accessible depuis Internet, son port SSH reçoit des tentatives de connexion automatisées en continu, essayant des combinaisons courantes de nom d’utilisateur et mot de passe. Sans protection, c’est une question de temps avant qu’un mot de passe faible ne cède. La solution n’est pas de cacher SSH, mais de rendre l’authentification par mot de passe impossible et de limiter les tentatives.
1. Connexion par clé plutôt que mot de passe
Sur votre poste client, générez une paire de clés si vous n’en avez pas :
ssh-keygen -t ed25519 -C "alice@monposte"
Copiez la clé publique sur le serveur :
ssh-copy-id alice@IP_DU_SERVEUR
Vérifiez que la connexion fonctionne sans mot de passe avant de passer à l’étape suivante :
ssh alice@IP_DU_SERVEUR
Pour gérer plusieurs serveurs sans retaper les options à chaque fois, créez un fichier ~/.ssh/config sur votre poste client avec un alias par serveur (Host, HostName, User, IdentityFile).
2. Durcir sshd_config
Une fois la connexion par clé confirmée, éditez la configuration du serveur SSH :
sudo vim /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
sudo systemctl restart ssh
Gardez votre session SSH actuelle ouverte pendant le test et ouvrez un second terminal pour tenter une nouvelle connexion. Si elle échoue, vous pourrez corriger depuis la session encore ouverte au lieu de vous retrouver enfermé dehors.
3. Bloquer les tentatives d’intrusion avec fail2ban
fail2ban surveille les journaux d’authentification et bannit temporairement (via le pare-feu) les adresses IP qui multiplient les échecs de connexion :
sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
La configuration par défaut protège déjà SSH sans réglage supplémentaire. Pour personnaliser (durée de bannissement, seuil de tentatives), copiez /etc/fail2ban/jail.conf vers /etc/fail2ban/jail.local avant de modifier quoi que ce soit.
4. Ouvrir le pare-feu proprement
Sur Debian/Ubuntu, ufw (Uncomplicated Firewall) simplifie la gestion d’iptables :
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status
Activez toujours la règle SSH avant d’activer ufw : dans le mauvais ordre, vous risquez de couper votre propre accès distant.
FAQ — Sécuriser SSH
Faut-il changer le port SSH par défaut (22) ?
Cela réduit le bruit des scans automatiques les plus basiques, mais n’apporte pas de vraie sécurité face à un attaquant ciblé. La clé SSH et fail2ban sont bien plus efficaces ; changer le port reste une option complémentaire, pas une protection en soi.
Je me suis enfermé dehors après une mauvaise configuration, que faire ?
Si vous hébergez sur un fournisseur cloud, utilisez la console web (VNC) fournie par l’hébergeur pour corriger sshd_config directement. C’est pourquoi il faut toujours garder une session ouverte pendant les tests.
fail2ban remplace-t-il le pare-feu ?
Non, il le complète : fail2ban ajoute des règles temporaires au pare-feu existant en réaction à des échecs d’authentification, il ne gère pas les autres règles réseau.
Conclusion
Sécuriser SSH repose sur trois piliers complémentaires : l’authentification par clé (qui rend le mot de passe inutile), un sshd_config durci (qui interdit root et les mots de passe), et fail2ban (qui bannit automatiquement les IP suspectes). Appliqués ensemble, ils suffisent à protéger un serveur Debian ou Ubuntu exposé sur Internet.
À lire aussi — Administration serveur Linux :
