SSH est la porte d’entrée de votre serveur, et sur Internet les portes sont testées des milliers de fois par jour. Il suffit de démarrer une machine neuve et de consulter les journaux quelques heures plus tard : vous verrez des tentatives d’accès venues du monde entier essayant des noms d’utilisateur courants et des mots de passe de dictionnaire. Ce n’est pas personnel, c’est automatisé.
La bonne nouvelle, c’est que trois mesures éliminent l’essentiel du risque, et aucune n’est compliquée.
Un : des clés plutôt que des mots de passe
Une clé SSH est une paire de fichiers : une publique qui vit sur le serveur et une privée qui ne quitte jamais votre ordinateur. L’avantage n’est pas seulement la longueur, c’est que le secret ne voyage pas : il n’y a rien qu’un attaquant puisse deviner par force brute.
Générez votre paire avec ssh-keygen -t ed25519, copiez la publique sur le serveur, vérifiez que vous vous connectez avec elle, et seulement ensuite désactivez l’authentification par mot de passe. Cet ordre compte : désactiver avant de vérifier est le moyen le plus rapide de vous enfermer dehors.
Si vous gardez des mots de passe, faites-le bien
Parfois le mot de passe est nécessaire, par exemple pour entrer depuis une console web sans votre clé. Dans ce cas, deux règles : long, vingt caractères ou plus, et sans symboles exotiques. Les consoles distantes traduisent les caractères selon la disposition clavier du client : un symbole nécessitant la touche majuscule peut arriver transformé. C’est une source classique de frustration : vous tapez le bon mot de passe et le serveur en reçoit un autre.
Deux : un port alternatif
Remplacer le port 22 par un autre n’est pas de la sécurité réelle, et qui vous dit le contraire exagère. Un scan de ports trouve votre SSH sur n’importe quel port en quelques secondes.
Mais cela apporte deux bénéfices concrets. D’abord, cela réduit drastiquement le bruit : les bots qui balaient Internet ne testent que le 22, vos journaux passent donc de milliers de tentatives quotidiennes à presque aucune, et quand une vraie apparaît, vous la voyez.
Ensuite, c’est plus pratique qu’il n’y paraît : certains réseaux d’entreprise et certains opérateurs de transit filtrent le port 22 par politique. Un port alternatif ouvert vous offre un chemin quand le standard ne passe pas. Notre recommandation : garder les deux.
Trois : expulser les insistants
Installez fail2ban ou un équivalent. Il surveille les journaux et, quand une adresse échoue plusieurs fois de suite, la bloque temporairement au pare-feu. Mesure peu coûteuse qui coupe net les attaques par force brute lentes, celles qui essaient trois mots de passe par heure pour rester discrètes.
Le détail que presque personne ne vérifie
Tout ce qui précède figure dans n’importe quel guide. Voici ce qu’on oublie : vérifiez qui peut réellement se connecter.
Chaque compte avec accès SSH est une porte de plus. Le compte créé pour un développeur qui ne travaille plus avec vous, l’utilisateur d’une application abandonnée, la clé publique d’un portable perdu. Un sshd -T montre la politique effective du serveur, et relire les fichiers de clés autorisées de chaque utilisateur prend cinq minutes.
Moins d’utilisateurs, moins de surface. Et désactivez la connexion root directe par mot de passe : connectez-vous avec votre compte et élevez vos droits avec sudo, pour garder une trace de qui a fait quoi.
Un avertissement sur les tests
Avant de recharger la configuration SSH, lancez toujours sshd -t pour valider la syntaxe. Et si vous travaillez à distance, ouvrez une seconde session avant d’appliquer les changements : en cas de problème, cette session ouverte est votre bouée.
Comment nous le livrons
Nos VPS en Andorre sont livrés avec accès root, des mots de passe alphanumériques qui ne cassent pas dans les consoles web, et deux ports SSH configurés d’origine précisément à cause du filtrage en transit. Et comme tout durcissement finit par mal tourner un jour, l’option de sauvegarde vous permet de revenir en arrière en quelques minutes.