SSH est la porte d'entrée de votre serveur : c'est par lui que vous administrez la machine, déployez le code et consultez les journaux. C'est aussi le service le plus attaqué par les robots qui balaient Internet en continu. Prendre le temps de sécuriser SSH dès l'installation d'un VPS est donc une priorité absolue. Voici la configuration que j'applique sur tous les serveurs que je gère, étape par étape, et dans un ordre qui évite de se retrouver enfermé dehors.
Règle n°1 : garder une porte de secours
Avant de modifier la configuration de SSH, assurez-vous de disposer d'un accès de secours : la console web (KVM) proposée par votre hébergeur dans son espace client. Gardez aussi une session SSH ouverte pendant toutes les manipulations, et testez chaque changement depuis une seconde session. Si la nouvelle connexion échoue, la première vous permet de corriger.
Étape 1 : utiliser des clés plutôt que des mots de passe
Une clé SSH est incomparablement plus robuste qu'un mot de passe : impossible à deviner par force brute, elle ne transite jamais sur le réseau. Sur votre ordinateur, générez une clé de type Ed25519, le type recommandé aujourd'hui :
ssh-keygen -t ed25519 -C "benjamin@poste-bureau"
Protégez la clé privée par une phrase de passe : si votre ordinateur est volé, la clé seule ne suffira pas. Copiez ensuite la clé publique sur le serveur :
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@203.0.113.10
Vérifiez que la connexion par clé fonctionne avant de passer à l'étape suivante.
Étape 2 : créer un utilisateur dédié
Ne travaillez pas directement avec le compte root. Créez un utilisateur d'administration qui utilisera sudo pour les commandes privilégiées :
adduser admin
usermod -aG sudo admin
Chaque action privilégiée laisse ainsi une trace dans les journaux, et une erreur de manipulation est moins lourde de conséquences.
Étape 3 : durcir la configuration du serveur SSH
Sur Debian et Ubuntu, le fichier principal /etc/ssh/sshd_config inclut les fichiers du dossier /etc/ssh/sshd_config.d/. Placez vos réglages dans un fichier séparé : ils survivront aux mises à jour du paquet.
# /etc/ssh/sshd_config.d/10-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
AllowUsers admin deploy
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
Ce que font ces directives :
- PermitRootLogin no : interdit la connexion directe en root ;
- PasswordAuthentication no et KbdInteractiveAuthentication no : seules les clés sont acceptées, les attaques par dictionnaire deviennent inutiles ;
- AllowUsers : seuls les comptes listés peuvent se connecter, même si un autre compte est créé par erreur ou par une application ;
- MaxAuthTries et LoginGraceTime : limitent le temps et le nombre d'essais par connexion ;
- X11Forwarding no : désactive une fonctionnalité graphique inutile sur un serveur web.
Avant de recharger le service, testez la syntaxe : une erreur de frappe pourrait empêcher SSH de redémarrer.
sudo sshd -t && sudo systemctl reload ssh
Puis ouvrez une nouvelle session pour confirmer que tout fonctionne. La liste complète des options est décrite dans la documentation d'OpenSSH.
Étape 4 : filtrer l'accès au port SSH
Un pare-feu ne doit laisser passer que les services réellement utilisés. Avec UFW, la règle limit ralentit en plus les connexions répétées :
sudo ufw limit 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
Si vous vous connectez toujours depuis une adresse IP fixe, vous pouvez réserver le port SSH à cette seule adresse. C'est très efficace, mais prévoyez la console de secours en cas de changement d'adresse.
Faut-il changer le port 22 ? Déplacer SSH sur un autre port réduit le bruit dans les journaux, mais n'apporte aucune sécurité réelle : un balayage de ports le retrouve en quelques secondes. Ce n'est pas une mesure de sécurité en soi, simplement un confort.
Étape 5 : bannir les adresses trop insistantes
Même avec l'authentification par clé, les robots continuent d'essayer. Fail2ban repère ces tentatives répétées dans les journaux et bannit temporairement les adresses concernées : les journaux restent lisibles et les ressources du serveur sont préservées.
Étape 6 : gérer les clés dans la durée
La sécurité de SSH ne s'arrête pas à l'installation :
- Une clé par personne et par appareil : quand un prestataire termine sa mission ou qu'un ordinateur est remplacé, on retire la clé correspondante du fichier
~/.ssh/authorized_keys; - Des clés de déploiement à part : un outil d'intégration continue utilise sa propre clé, limitée à un compte sans droits d'administration ;
- Un inventaire à jour : sachez à tout moment qui peut accéder à quel serveur. C'est aussi un point clé quand on change de prestataire web.
Les clés privées, comme tous les secrets, ne doivent jamais se retrouver dans un dépôt Git ou un e-mail. Mon article sur la gestion des secrets détaille les bonnes pratiques.
Une base, pas une fin
Ces réglages éliminent l'immense majorité des attaques automatisées contre SSH. Ils s'inscrivent dans une démarche plus large : mises à jour de sécurité automatiques, pare-feu restrictif, sauvegardes externalisées et surveillance. Pour les commandes de base de l'administration, consultez aussi mon mémo sur les commandes Linux essentielles.
Vous avez un VPS et vous n'êtes pas certain de sa configuration ? Je propose un audit de sécurité serveur avec un rapport clair et les corrections à appliquer.
