10 bonnes pratiques essentielles pour renforcer votre serveur SSH

Secure Shell (SSH) est généralement la porte d'entrée de votre serveur. Si cette porte accepte des mots de passe faibles, des connexions root directes ou du trafic provenant de tout Internet, les attaquants la trouveront rapidement.

Ce guide vous donne 10 étapes pratiques pour renforcer votre serveur SSH, applicables à OpenSSH sur les distributions Linux courantes. Gardez une session de travail ouverte pendant que vous testez chaque modification afin de pouvoir récupérer si une règle de pare-feu ou une modification de configuration bloque les nouvelles connexions.

1. Modifier le port SSH par défaut

Le port SSH par défaut est 22. Il est universellement connu et constamment scanné par des bots automatisés à la recherche de serveurs vulnérables. Changer le port par défaut offre une couche d'obscurité simple mais efficace. Bien que cela ne constitue pas une mesure de sécurité en soi, cela réduit considérablement le bruit des scans automatisés et aide à éviter de nombreuses attaques opportunistes.

Pour changer le port, modifiez le fichier sshd_config, généralement situé dans /etc/ssh/sshd_config.

sudo nano /etc/ssh/sshd_config

Trouvez la ligne Port 22 (ou ajoutez-la si elle n'existe pas) et remplacez 22 par un numéro de port non standard et non attribué (par exemple, 2222, 49152-65535 sont des ports utilisateur/dynamiques).

#Port 22
Port 2222

Avant de redémarrer SSH, autorisez le nouveau port dans votre pare-feu. Ensuite, testez une nouvelle connexion sur le nouveau port avant de supprimer l'accès au port 22.

# Pour UFW (Uncomplicated Firewall) :
sudo ufw allow 2222/tcp
sudo ufw reload

# Pour Firewalld :
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

sudo sshd -t
sudo systemctl restart sshd

Astuce : Gardez toujours au moins une session SSH ouverte pendant que vous testez les modifications de configuration. Si vous êtes verrouillé, vous pouvez annuler les modifications dans la session active.

2. Désactiver la connexion root

La connexion root directe via SSH est fortement déconseillée. L'utilisateur root a des privilèges illimités, ce qui en fait une cible de choix pour les attaquants. Si un attaquant obtient un accès root, il a un contrôle total sur votre système. Au lieu de cela, connectez-vous en tant qu'utilisateur normal et non privilégié, puis utilisez sudo pour effectuer des tâches administratives.

Dans sshd_config, trouvez la directive PermitRootLogin et définissez-la sur no.

PermitRootLogin no

Enregistrez et redémarrez le service SSH :

sudo systemctl restart sshd

3. Utiliser l'authentification par clé

L'authentification par mot de passe est vulnérable aux attaques par force brute et par dictionnaire, surtout si les utilisateurs choisissent des mots de passe faibles. L'authentification par clé SSH est une alternative beaucoup plus sécurisée. Elle utilise une paire de clés cryptographiques : une clé publique stockée sur le serveur et une clé privée conservée sur votre machine locale. Seuls les clients disposant de la clé privée correspondante peuvent s'authentifier.

Étapes pour mettre en œuvre l'authentification par clé (brièvement) :

1. Générez une paire de clés sur votre machine locale :

   ssh-keygen -t ed25519 -C "[email protected]"
   

   • ed25519 est un algorithme moderne et sécurisé avec une taille de clé fixe. rsa est également courant ; si vous utilisez RSA, générez une grande clé comme ssh-keygen -t rsa -b 4096.

2. Copiez la clé publique sur votre serveur :

   ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@adresse_ip_serveur
   

   Sinon, ajoutez manuellement le contenu de ~/.ssh/id_ed25519.pub dans ~/.ssh/authorized_keys sur le serveur pour l'utilisateur avec lequel vous souhaitez vous connecter.

3. Assurez-vous des permissions correctes sur le serveur :

   • Répertoire ~/.ssh : 700 (rwx pour le propriétaire uniquement)
   • Fichier ~/.ssh/authorized_keys : 600 (rw pour le propriétaire uniquement)

   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys
   

4. Désactiver l'authentification par mot de passe

Une fois que vous avez configuré et testé avec succès l'authentification par clé pour tous les utilisateurs nécessaires, vous devez désactiver complètement l'authentification par mot de passe. Cela supprime le maillon le plus faible de la sécurité SSH en rendant les attaques par force brute sur les mots de passe impossibles.

Dans sshd_config, définissez PasswordAuthentication sur no.

PasswordAuthentication no
KbdInteractiveAuthentication no

Sur certaines distributions, l'authentification PAM ou interactive par clavier peut encore demander des mots de passe à moins que vous ne la désactiviez également. Testez avec un nouveau terminal avant de fermer votre session existante.

Enregistrez et redémarrez le service SSH :

sudo systemctl restart sshd

Avertissement : Ne désactivez jamais l'authentification par mot de passe avant d'avoir vérifié que l'authentification par clé fonctionne correctement pour tous les utilisateurs qui ont besoin d'accès. Sinon, vous risquez de vous verrouiller hors du serveur.

5. Limiter l'accès des utilisateurs

Par défaut, tout compte utilisateur sur le serveur peut tenter de se connecter via SSH. Vous pouvez restreindre l'accès SSH à des utilisateurs ou groupes spécifiques, minimisant ainsi la surface d'attaque.

Utilisez les directives AllowUsers ou AllowGroups dans sshd_config.

Pour autoriser uniquement des utilisateurs spécifiques (par exemple, adminuser, devuser) :

AllowUsers adminuser devuser

Pour autoriser uniquement les membres d'un groupe spécifique (par exemple, sshusers) :

AllowGroups sshusers

Astuce : Il est généralement préférable d'utiliser AllowGroups si vous avez plusieurs utilisateurs. Créez un groupe dédié pour l'accès SSH et ajoutez-y les utilisateurs autorisés.

sudo groupadd sshusers
sudo usermod -aG sshusers adminuser
sudo usermod -aG sshusers devuser

Après avoir effectué les modifications, enregistrez et redémarrez SSH.

6. Utiliser des phrases de passe fortes pour les clés SSH

Bien que l'authentification par clé soit robuste, votre clé privée reste un actif critique. Si un attaquant accède à votre machine locale, il pourrait voler votre clé privée. Une phrase de passe forte chiffre votre clé privée, nécessitant la phrase de passe pour la déverrouiller avant utilisation. Cela ajoute une couche de sécurité supplémentaire, protégeant votre clé même si elle tombe entre de mauvaises mains.

Lors de la génération de votre clé SSH (comme à l'étape 3), une phrase de passe vous sera demandée. Choisissez une phrase de passe longue, complexe et mémorisable, différente de tout autre mot de passe que vous utilisez.

7. Mettre en œuvre une limitation du débit de connexion (Fail2Ban)

Même avec l'authentification par clé, un serveur SSH est toujours sujet à des tentatives de connexion. Des outils comme Fail2Ban peuvent surveiller activement les journaux SSH pour détecter les tentatives de connexion échouées répétées provenant de la même adresse IP et bloquer automatiquement cette adresse IP à l'aide de règles de pare-feu pendant une période définie.

Installation (exemple pour Debian/Ubuntu) :

sudo apt update
sudo apt install fail2ban

Fail2Ban fonctionne immédiatement avec les règles SSH par défaut, mais vous pouvez personnaliser sa configuration en copiant jail.conf vers jail.local et en l'éditant.

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Dans jail.local, vous pouvez ajuster bantime, findtime et maxretry pour la section [sshd].

[sshd]
enabled = true
port = 2222 # Votre nouveau port SSH
logpath = %(sshd_log)s
maxretry = 3
bantime = 1h
findtime = 10m

Redémarrez Fail2Ban après les modifications de configuration :

sudo systemctl restart fail2ban

8. Maintenir votre logiciel serveur SSH à jour

Des vulnérabilités logicielles sont constamment découvertes et corrigées. L'utilisation d'un logiciel de démon SSH (OpenSSH) obsolète signifie que vous pourriez être exposé à des exploits connus. Mettre régulièrement à jour les logiciels de votre serveur, y compris le paquet du serveur OpenSSH, est crucial pour corriger les vulnérabilités de sécurité.

# Pour Debian/Ubuntu :
sudo apt update && sudo apt upgrade

# Pour CentOS/RHEL :
sudo yum update
# ou
sudo dnf update

Configurez votre système pour appliquer automatiquement les mises à jour de sécurité lorsque cela est approprié, ou établissez une routine pour les mises à jour manuelles.

9. Surveiller les journaux SSH pour détecter une activité suspecte

Même avec des mesures préventives robustes, la vigilance est essentielle. Examinez régulièrement les journaux d'authentification SSH pour détecter des schémas inhabituels, des tentatives de connexion échouées ou des tentatives d'accès non autorisées. Cela vous aide à identifier les violations potentielles ou les attaques en cours.

Les journaux SSH se trouvent généralement dans :

• /var/log/auth.log (Debian/Ubuntu)
• /var/log/secure (CentOS/RHEL)
• En utilisant journalctl (systèmes systemd) :

  sudo journalctl -u sshd -f
  

Recherchez les tentatives d'authentification échouées répétées, les connexions provenant d'adresses IP inhabituelles ou les connexions réussies par des utilisateurs inconnus. Des outils comme Logwatch ou Elastic Stack (ELK) peuvent automatiser l'analyse des journaux et les alertes pour les environnements plus vastes.

10. Configurer les règles de pare-feu pour restreindre l'accès

Un pare-feu est votre première ligne de défense. Par défaut, il doit bloquer tout le trafic entrant, à l'exception des services que vous devez explicitement exposer. Pour SSH, cela signifie autoriser les connexions uniquement sur le port que vous avez choisi (par exemple, 2222) et, idéalement, uniquement à partir d'adresses IP ou de réseaux de confiance spécifiques.

Exemple avec UFW (Uncomplicated Firewall) :

Autoriser SSH depuis une adresse IP spécifique 192.168.1.100 sur le port 2222 :

sudo ufw allow from 192.168.1.100 to any port 2222

Autoriser SSH depuis un sous-réseau spécifique 192.168.1.0/24 :

sudo ufw allow from 192.168.1.0/24 to any port 2222

Exemple avec Firewalld (CentOS/RHEL) :

Autoriser SSH depuis une adresse IP spécifique 192.168.1.100 sur le port 2222 :

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port=2222 protocol="tcp" accept'
sudo firewall-cmd --reload

Avertissement : Si vous gérez un serveur à partir d'une adresse IP dynamique, soyez prudent avec des règles de pare-feu strictes. Vous devrez peut-être autoriser l'accès depuis une plage plus large ou utiliser un VPN.

Conseils supplémentaires pour le renforcement

Au-delà des 10 essentiels, considérez ces directives pour une sécurité encore plus grande :

• MaxAuthTries : Limite le nombre de tentatives d'authentification par connexion. La valeur par défaut est 6. La réduire (par exemple, 3) diminue les chances de force brute. Définir dans sshd_config.

  MaxAuthTries 3
  

• LoginGraceTime : Limite le temps accordé à un utilisateur pour s'authentifier. La valeur par défaut est 2 minutes. La réduire (par exemple, 30s) réduit la fenêtre pour les attaques lentes.

  LoginGraceTime 30s
  

• ClientAliveInterval et ClientAliveCountMax : Empêchent les sessions SSH inactives de rester ouvertes indéfiniment. ClientAliveInterval envoie un message keepalive toutes les X secondes. Si ClientAliveCountMax réponses sont manquées, la connexion est terminée.

  ClientAliveInterval 300
  ClientAliveCountMax 2
  

• Banner : Affiche un message d'avertissement avant l'authentification. Cela sert d'avis légal aux utilisateurs non autorisés potentiels.

  Banner /etc/issue.net
  

  Créez le fichier /etc/issue.net avec votre message d'avertissement souhaité.

À retenir en pratique

Commencez par les modifications qui suppriment le plus grand risque : désactivez la connexion root, exigez des clés SSH, restreignez qui peut se connecter et limitez les réseaux sources lorsque vous le pouvez. Testez chaque modification avec sshd -t et une nouvelle session de connexion avant de fermer votre session actuelle.