Limiter les tentatives de connexion SSH sur un VPS Linux

Des tentatives de connexion SSH répétées apparaissent dans les journaux de votre serveur VPS Linux ? La bonne réponse consiste à réduire la surface d’attaque sans vous enfermer dehors. Ce guide propose une méthode progressive sur un serveur privé virtuel : vérifier l’accès administrateur, renforcer l’authentification, observer les journaux, puis automatiser le blocage avec Fail2ban si votre distribution le permet.

Avant de commencer : conserver un accès de secours

Gardez une session SSH déjà ouverte pendant les changements et vérifiez que vous disposez d’un accès console fourni par votre hébergeur. Notez le nom du compte d’administration, le port SSH réellement utilisé, l’adresse IP depuis laquelle vous intervenez et le nom de domaine éventuellement associé au VPS. Une règle de pare-feu ou un bannissement mal ciblé peut couper votre connexion légitime.

Cette précaution vaut pour un VPS Ubuntu, Debian ou une autre distribution Linux. Elle vaut aussi si la machine héberge un serveur Web, une base de données MySQL, Apache, des scripts ou un panneau de contrôle : la sécurité SSH doit rester distincte de la configuration de ces applications. Consultez également notre guide sur les premiers réglages de sécurité d’un serveur dédié et celui consacré au diagnostic d’un VPS inaccessible.

Lire les journaux avant de bloquer

Commencez par identifier le service qui enregistre les connexions SSH sur votre système. Sur une machine utilisant systemd, journalctl permet de filtrer les messages du service SSH. Selon la distribution, le service peut être nommé ssh ou sshd. Sur d’autres installations, les événements peuvent aussi être écrits dans un fichier d’authentification.

Recherchez les échecs répétés, les utilisateurs ciblés et les adresses sources. Une série d’échecs n’est pas une preuve qu’un compte a été compromis : elle indique surtout qu’une politique de limitation mérite d’être mise en place. Vérifiez aussi que la partition contenant les journaux ne manque pas d’espace disque. Pour une méthode d’administration complémentaire, consultez notre guide sur Docker sur un VPS.

Renforcer l’authentification SSH

La mesure la plus importante est d’utiliser une clé SSH protégée par une phrase secrète lorsque votre environnement le permet. Testez la nouvelle clé dans une seconde session avant d’envisager de désactiver l’authentification par mot de passe. Ne supprimez pas l’unique méthode d’accès tant que la méthode de remplacement n’a pas été validée.

Évitez aussi les connexions directes du compte root lorsque votre politique d’administration prévoit un compte nominatif avec élévation de privilèges via sudo. Les paramètres exacts dépendent de votre distribution et de votre modèle d’exploitation. Après toute modification de configuration SSH, contrôlez la syntaxe puis rechargez uniquement le service concerné. Un changement de port peut réduire le bruit dans les journaux, mais ce n’est pas un mécanisme d’authentification à lui seul.

Vérifier le pare-feu et les ports

Avant d’ajouter une règle, établissez la liste des services réellement nécessaires : SSH pour l’administration, HTTP et HTTPS pour un serveur Web, DNS si la machine assure ce rôle, ou les ports de votre application. Un port ouvert ne signifie pas qu’un service est correctement sécurisé, et un port fermé peut rendre un site, une API ou un serveur de jeu inaccessible.

Si vous utilisez UFW ou un autre firewall, autorisez d’abord votre accès SSH, testez la règle depuis une seconde session, puis contrôlez l’état du pare-feu. N’appliquez pas aveuglément une configuration prévue pour un serveur mutualisé, un hébergement Web ou un panneau Plesk à un VPS qui n’a pas les mêmes services. Documentez chaque règle et retirez les accès inutiles.

Limiter automatiquement les tentatives

Fail2ban peut surveiller les journaux, compter les échecs selon une fenêtre de temps et ajouter temporairement une adresse à une action de bannissement. Cette protection ne remplace ni les clés SSH, ni les mises à jour, ni une règle réseau correctement définie. Elle doit être configurée avec des valeurs compréhensibles : durée de bannissement, nombre d’échecs tolérés et période d’observation.

Commencez par une politique prudente, autorisez explicitement vos adresses d’administration lorsque c’est pertinent, puis observez les journaux de Fail2ban. Ne copiez pas une configuration trouvée au hasard : le nom du filtre, le chemin des journaux et le gestionnaire de service changent selon le système. La documentation de votre distribution reste la référence pour ces détails.

Vérifier les ressources du VPS

Une saturation de RAM, de CPU ou de stockage peut compliquer l’analyse des connexions et retarder les services de sécurité. Contrôlez l’utilisation mémoire, l’espace de stockage disponible sur le SSD ou le disque virtuel, ainsi que la charge CPU lorsque vous examinez un pic de tentatives. Un serveur Web, une base MySQL, des sauvegardes et des scripts planifiés partagent les mêmes ressources que SSH.

Un serveur VPS est un serveur virtuel avec des ressources attribuées dans une infrastructure d’hébergement cloud. Sa flexibilité permet d’administrer un système Linux sans gérer directement le serveur physique, mais la bande passante, le stockage et la mémoire restent des ressources à surveiller. Plusieurs serveurs virtuels peuvent avoir des usages différents : ne mélangez pas les règles d’un VPS de test, d’un serveur privé de production et d’un serveur dédié.

Prévoir maintenance et reprise

Conservez une sauvegarde de la configuration SSH et vérifiez régulièrement que vos sauvegardes sont restaurables. Une sauvegarde ne protège pas contre une mauvaise règle en temps réel, mais elle facilite la reprise après une erreur de configuration. Pour un service important, documentez les dépendances réseau, l’adresse IP, le DNS, les ports et la procédure d’accès console.

La haute disponibilité, la redondance ou plusieurs serveurs peuvent répondre à des besoins d’exploitation différents, mais ils ne remplacent pas une authentification SSH robuste. Dimensionnez le serveur VPS selon le trafic et les services réellement utilisés au lieu d’ouvrir des accès supplémentaires sans contrôle.

Vérifier après chaque changement

Ouvrez une nouvelle connexion depuis votre poste d’administration, confirmez qu’elle fonctionne, puis contrôlez les événements produits. Vérifiez également que le bannissement expire comme prévu et qu’une adresse légitime peut être retirée de la liste si nécessaire. Conservez une copie de la configuration validée et documentez la procédure de récupération console.

Si le problème porte plutôt sur un port distant bloqué, utilisez notre guide pour diagnostiquer un port RDP bloqué. Pour les serveurs de jeu, séparez bien le port SSH des ports utilisés par votre application et consultez notre guide pour sécuriser un serveur de jeu.

Checklist de limitation des tentatives SSH

• Une session de secours ou une console est disponible.
• Une clé SSH fonctionnelle a été testée dans une seconde session.
• Les échecs ont été observés dans le bon journal.
• Le compte d’administration utilise une politique sudo cohérente.
• Le pare-feu n’expose que les services nécessaires.
• La politique de bannissement est progressive et documentée.
• Votre adresse d’administration ne risque pas d’être bannie par erreur.
• Le fonctionnement a été vérifié après rechargement du service.