Renforcer la sécurité du serveur SSH

Un serveur SSH exposé à Internet est une cible permanente pour les attaques automatisées. Les paramètres par défaut laissent plusieurs portes ouvertes que les robots sondent sans relâche.

Renforcer la sécurité consiste à resserrer la configuration côté serveur afin que, même si des attaquants trouvent votre serveur, ils ne puissent pas y accéder par force brute.

Le comportement de SSH côté serveur est contrôlé par /etc/ssh/sshd_config. Ce fichier est différent de la configuration du client que vous avez configurée précédemment (~/.ssh/config).

Modifiez-le toujours en tant que root et conservez une sauvegarde avant d’effectuer des changements.

Le compte root est la première cible des attaquants. Désactiver la connexion directe de root les oblige également à deviner un nom d’utilisateur valide.

Définissez PermitRootLogin sur no. Les administrateurs doivent se connecter avec un utilisateur normal et utiliser sudo.

Une fois l’authentification par clé opérationnelle, désactivez complètement les mots de passe. Cela neutralise entièrement les attaques par force brute — il n’y a aucun mot de passe à deviner.

Avertissement : vérifiez que la connexion par clé fonctionne avant d’appliquer cette modification, sinon vous risquez de vous retrouver bloqué.

Vous pouvez établir une liste blanche des comptes autorisés à utiliser SSH avec AllowUsers ou AllowGroups. Toute personne qui n’y figure pas sera refusée, même avec des clés valides.

Il s’agit d’un contrôle simple et efficace sur les serveurs accueillant plusieurs utilisateurs.

Déplacer SSH du port 22 n’ajoute pas de véritable sécurité, mais réduit considérablement le bruit généré par les analyseurs automatisés dans vos journaux.

Choisissez un port non standard et n’oubliez pas de l’ouvrir dans votre pare-feu et d’en informer vos clients.

Plusieurs directives réduisent la marge de manœuvre des attaquants :

• MaxAuthTries — tentatives échouées avant la déconnexion
• LoginGraceTime — nombre de secondes accordées pour s’authentifier
• MaxSessions — nombre de sessions simultanées par connexion

Après la modification, validez la syntaxe avec sshd -t avant de redémarrer : une faute de frappe peut empêcher le service de démarrer et vous bloquer hors du serveur.

Rechargez ensuite le service. Gardez votre session actuelle ouverte et testez une nouvelle connexion avant de la fermer.

Fail2ban surveille vos journaux d’authentification et bannit temporairement les adresses IP qui échouent trop souvent. Il ajoute une couche de pare-feu dynamique par-dessus la configuration de sshd.

Installez-le et activez la prison SSH : les valeurs par défaut conviennent à la plupart des serveurs.

Confirmez que le serveur rejette désormais les éléments que vous avez désactivés. Essayez de vous connecter avec une sortie détaillée pour voir quelles méthodes d’authentification le serveur propose.

Un serveur renforcé ne devrait annoncer que publickey et refuser les connexions par mot de passe et celles de root.

Maintenez la sécurité de votre serveur SSH au fil du temps :

• N’appliquez jamais PasswordAuthentication no avant d’avoir testé la connexion par clé
• Gardez une session ouverte pendant la modification de la configuration
• Utilisez sshd -t après chaque modification
• Combinez le renforcement de sshd avec un pare-feu et Fail2ban

Testez vos connaissances sur le renforcement de SSH.

Vous avez renforcé votre serveur SSH au moyen de /etc/ssh/sshd_config :

• Désactivation des connexions de root et par mot de passe
• Ajout d’une liste blanche d’utilisateurs avec AllowUsers
• Ajustement de MaxAuthTries et LoginGraceTime
• Ajout de Fail2ban pour une protection dynamique contre la force brute

Validez avec sshd -t et testez toujours avant de fermer votre session.