Aller au contenu
Sécurité medium

Durcir la configuration SSH

15 min de lecture

Laisser la configuration SSH par défaut expose votre serveur à de nombreuses vulnérabilités. Par défaut, certains paramètres offrent peu de restrictions, facilitant ainsi les attaques par force brute, les tentatives d’accès non autorisées et l’exploitation de failles connues. Un serveur mal configuré devient une cible facile pour les attaquants cherchant à compromettre votre système. Personnaliser et durcir la configuration est donc essentiel pour réduire ces risques et garantir un accès sécurisé à votre machine. Dans ce guide, je vous montre comment renforcer votre config SSH avec des bonnes pratiques éprouvées.

OpenSSH est omniprésent dans les infrastructures informatiques, servant de pilier pour les connexions sécurisées à distance. Cette large adoption en fait une cible privilégiée pour les attaquants. Ainsi, la mise à jour régulière d’OpenSSH est une mesure essentielle pour maintenir la sécurité de vos systèmes.

Par exemple, en juillet 2024, la vulnérabilité RegreSSHion (CVE-2024-6387) a été découverte dans les versions 8.5p1 à 9.7p1 d’OpenSSH. Cette faille permettait à un attaquant distant non authentifié d’exécuter du code arbitraire avec des privilèges root, compromettant ainsi gravement la sécurité du système. La mise à jour vers la version 9.8p1 a corrigé cette vulnérabilité.

De plus, en février 2025, une vulnérabilité critique (CVE-2025-26465) a été identifiée dans OpenSSH. Cette faille permettait à un attaquant d’usurper l’identité d’un serveur légitime, facilitant ainsi des attaques de type “man-in-the-middle”. La mise à jour vers la version 9.9p2 a permis de résoudre ce problème.

Ces exemples illustrent l’importance de maintenir OpenSSH à jour pour se protéger contre des vulnérabilités critiques. Négliger les mises à jour expose votre infrastructure à des risques majeurs. Il est donc recommandé de surveiller régulièrement les annonces de sécurité et d’appliquer les correctifs dès leur disponibilité.

Configurer correctement OpenSSH est une étape clé du durcissement de votre serveur. Par défaut, certaines options sont trop permissives, ce qui peut exposer votre infrastructure à des attaques par force brute, du vol d’identifiants ou des exploits de vulnérabilités connues. En ajustant le fichier de configuration /etc/ssh/sshd_config, on réduit drastiquement ces risques.

Voici les paramètres essentiels à modifier pour sécuriser votre serveur SSH :

Paramètres essentiels pour renforcer la sécurité

Section intitulée « Paramètres essentiels pour renforcer la sécurité »

Ajoutez ou modifiez ces lignes dans /etc/ssh/sshd_config, puis redémarrez le service SSH avec systemctl restart sshd pour appliquer les changements.

ParamètreValeur recommandéeExplication
Protocol2Seule la version 2 du protocole SSH doit être utilisée. La version 1 est obsolète et vulnérable.
LogLevelVERBOSEActive des logs détaillés pour mieux détecter des activités suspectes dans /var/log/auth.log.
PermitRootLoginnoDésactive la connexion SSH en root pour limiter les risques d’attaques ciblant ce compte.
PasswordAuthenticationnoInterdit l’authentification par mot de passe au profit des clés SSH.
ChallengeResponseAuthenticationnoDésactive les méthodes d’authentification interactives vulnérables aux attaques de phishing.
AllowAgentForwardingnoBloque l’agent forwarding SSH, utilisé parfois pour contourner les restrictions d’accès.
PermitTunnelnoDésactive la possibilité de créer des tunnels réseau via SSH pour limiter les abus.
X11ForwardingnoEmpêche le transfert de session graphique X11, souvent inutile et vecteur potentiel d’attaques.
MaxAuthTries3Limite le nombre de tentatives de connexion infructueuses avant déconnexion.
UsePAMyesActive PAM (Pluggable Authentication Modules) pour renforcer la sécurité des connexions SSH.
ClientAliveInterval0Désactive les requêtes de vie active des clients pour éviter des abus liés aux sessions inactives.
ClientAliveCountMax2Si ClientAliveInterval est activé, ferme la connexion après 2 requêtes sans réponse.
LoginGraceTime300Définit un délai de 5 minutes (300 secondes) avant qu’une tentative de connexion échoue si l’utilisateur ne s’authentifie pas.

Vérifier la syntaxe du fichier avant de redémarrer :

Fenêtre de terminal
sudo sshd -t

Une fois la configuration modifiée, appliquez les modifications avec :

Fenêtre de terminal
sudo systemctl restart sshd

Ce durcissement de la configuration réduit drastiquement la surface d’attaque et protège votre serveur contre les connexions non autorisées.

Sécuriser OpenSSH passe par une gestion rigoureuse des chiffrements (ciphers) et des algorithmes cryptographiques. Il est essentiel de désactiver les méthodes obsolètes ou vulnérables et d’adopter celles qui garantissent un haut niveau de sécurité.

Certains chiffrements et algorithmes sont aujourd’hui considérés comme inadaptés et doivent être évités. Parmi eux :

  • Ciphers vulnérables : arcfour, blowfish
  • Algorithmes d’échange de clés (KEX) faibles : diffie-hellman-group1-sha1
  • MACs (Message Authentication Codes) obsolètes : hmac-md5, hmac-sha1

Ces méthodes ne garantissent plus une protection suffisante contre les attaques modernes et doivent être remplacées.

Algorithmes recommandés pour une sécurité renforcée

Section intitulée « Algorithmes recommandés pour une sécurité renforcée »

Pour assurer une meilleure protection, privilégiez les ciphers, KEX et MACs les plus robustes :

  • Ciphers modernes : aes256-gcm@openssh.com, chacha20-poly1305@openssh.com
  • Algorithmes de Key Exchange sécurisés : curve25519-sha256, diffie-hellman-group-exchange-sha256
  • MACs recommandés : hmac-sha2-512-etm@openssh.com, umac-128-etm@openssh.com

Avant de redémarrer le service SSH, il est important de tester la configuration pour éviter tout risque de déconnexion :

Fenêtre de terminal
sudo sshd -t

Il est recommandé d’ajouter un fichier de configuration dédié dans /etc/ssh/sshd_config.d/, par exemple ciphers.conf. Pour modifier la configuration, utilisez un éditeur de texte avec des droits administrateur et ajoutez ces lignes :

Fenêtre de terminal
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com

Puis, appliquez les changements en redémarrant OpenSSH :

Fenêtre de terminal
sudo systemctl restart sshd

La gestion adéquate des ciphers et des algorithmes dans OpenSSH est une étape super important pour assurer la sécurité de votre serveur. En suivant ces recommandations et en effectuant les ajustements nécessaires, vous renforcez considérablement la protection contre diverses menaces de sécurité.

Durcir la configuration de OpenSSH est une tâche délicate, car les meilleures pratiques varient selon les distributions Linux et les exigences de sécurité propres à chaque environnement. C’est ici qu’intervient SSH-Audit, un outil essentiel pour analyser, identifier et corriger les faiblesses de votre serveur SSH. Il fournit un audit détaillé en mettant en évidence les éléments vulnérables et en suggérant des améliorations adaptées à votre système. Que vous soyez un administrateur expérimenté ou non, SSH-Audit simplifie l’optimisation de la sécurité de votre serveur OpenSSH.

SSH-Audit s’installe facilement via pip, le gestionnaire de paquets Python. Pour l’installer, exécutez la commande suivante dans un terminal :

Fenêtre de terminal
pip install ssh-audit

Une fois l’installation terminée, vous pouvez lancer une analyse de votre serveur SSH.

Pour analyser votre propre machine locale, utilisez simplement :

Fenêtre de terminal
ssh-audit localhost

Si vous souhaitez auditer un serveur distant, remplacez localhost par l’adresse IP ou le nom d’hôte du serveur cible :

Fenêtre de terminal
ssh-audit 192.168.1.100

SSH-Audit génère alors un rapport détaillé contenant :

  • La version d’OpenSSH utilisée et ses éventuelles vulnérabilités connues.
  • Les ciphers, MACs et algorithmes d’échange de clés en place.
  • Les configurations obsolètes, faibles ou dangereuses nécessitant une correction.

Une fois le rapport obtenu, il est essentiel d’analyser les résultats et de corriger les éventuelles failles. Par exemple :

  • Si SSH-Audit détecte des ciphers obsolètes, vous devez les désactiver dans le fichier de configuration /etc/ssh/sshd_config.d/ciphers.conf.
  • Si des algorithmes de Key Exchange dépassés sont utilisés, vous pouvez les remplacer par des alternatives plus robustes comme curve25519-sha256.

Voici un exemple de configuration sécurisée recommandée :

Fenêtre de terminal
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com

N’oubliez pas de redémarrer SSH après modification pour appliquer les changements :

Fenêtre de terminal
sudo systemctl restart sshd

À la fin du rapport, SSH-Audit fournit un lien vers des guides de configuration optimisés pour chaque distribution Linux. Vous pouvez les consulter ici :

🔗 Guides de durcissement SSH

En intégrant SSH-Audit à votre processus de maintenance, vous assurez une protection proactive contre les menaces potentielles. Un audit régulier permet de maintenir votre serveur SSH conforme aux meilleures pratiques de sécurité.

L’authentification par clé SSH est l’un des moyens les plus sécurisés pour se connecter à un serveur, bien plus fiable que l’authentification par mot de passe. Une clé SSH robuste garantit une protection efficace contre les attaques par force brute et le vol d’identifiants. Pour cela, il est essentiel de choisir un type de clé sécurisé, de renforcer sa protection et d’éviter les mauvaises pratiques.

Tous les types de clés SSH ne se valent pas. Certains sont obsolètes et vulnérables à des attaques cryptographiques. Voici les recommandations actuelles :

Type de cléRecommandation
RSAMinimum 4096 bits
Ed25519Recommandé, rapide et sécurisé
ECDSADéconseillé, remplacé par Ed25519
DSAObsolète, à éviter

Ed25519 est le meilleur choix : il est sécurisé, performant et plus court que RSA à même niveau de sécurité.

Pour générer une clé SSH robuste, utilisez la commande suivante en fonction du type choisi :

  • **Génération d’une clé Ed25519 :
Fenêtre de terminal
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "mon-utilisateur@serveur"
  • **Génération d’une clé RSA (4096 bits) :
Fenêtre de terminal
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -C "mon-utilisateur@serveur"
  • Protéger la clé avec un mot de passe lors de la génération : 👉 Il est recommandé d’ajouter une passphrase pour empêcher toute utilisation en cas de vol.

  • Restreindre les permissions de la clé privée :

    Fenêtre de terminal
    chmod 600 ~/.ssh/id_ed25519
    chmod 600 ~/.ssh/id_rsa

Une fois la clé générée, elle doit être déployée sur le serveur. Utilisez ssh-copy-id pour l’ajouter automatiquement à l’utilisateur distant :

Fenêtre de terminal
ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@serveur

Si ssh-copy-id n’est pas disponible, copiez manuellement la clé publique dans ~/.ssh/authorized_keys sur le serveur :

Fenêtre de terminal
cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Testez la connexion en spécifiant votre clé :

Fenêtre de terminal
ssh -i ~/.ssh/id_ed25519 utilisateur@serveur

Si tout est configuré correctement, la connexion se fera sans mot de passe et de manière sécurisée.

Bonne pratiques complémentaires pour sécuriser OpenSSH

Section intitulée « Bonne pratiques complémentaires pour sécuriser OpenSSH »

La sécurisation d’un serveur OpenSSH ne se limite pas à sa configuration initiale. Pour garantir une protection efficace face aux menaces en constante évolution, il est indispensable d’assurer une surveillance continue et d’appliquer des mises à jour régulières.

Une veille active sur les connexions SSH permet de détecter rapidement toute tentative d’intrusion ou activité suspecte. Voici les pratiques à adopter :

  • Analyse des logs SSH :

    • Les tentatives de connexion et erreurs d’authentification sont enregistrées dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL/CentOS).
    • Un outil comme Logwatch ou Swatchdog permet d’automatiser l’analyse et d’envoyer des alertes en cas d’activité anormale.
  • Détection des connexions suspectes :

    • Filtrer les connexions SSH par adresse IP permet d’identifier des tentatives répétées.

    • Une commande utile pour repérer les connexions :

      Fenêtre de terminal
      sudo grep "Failed password" /var/log/auth.log | awk '{print $NF}' | sort |
      uniq -c | sort -nr | head

Un suivi rigoureux des clés SSH est indispensable pour garantir un accès sécurisé.

  • Rotation régulière des clés : Il est recommandé de renouveler les clés périodiquement, notamment après un changement de personnel ou une modification de politique de sécurité.

  • Auditer les clés SSH autorisées : Vérifier régulièrement les clés présentes dans ~/.ssh/authorized_keys et supprimer celles qui ne sont plus utilisées :

    Fenêtre de terminal
    cat ~/.ssh/authorized_keys

Automatisation de la gestion et du durcissement SSH

Section intitulée « Automatisation de la gestion et du durcissement SSH »

Pour garantir une cohérence des configurations sur plusieurs serveurs et éviter les écarts liés aux erreurs humaines, il est recommandé d’utiliser des outils d’automatisation.

  • Rudder est un outil de gestion de configuration qui permet d’automatiser le durcissement SSH et de garantir la conformité des serveurs.
  • Ansible est une alternative légère permettant de déployer une configuration SSH sécurisée via des playbooks.

Après avoir durci votre configuration SSH, complétez votre expertise sécurité :

Sécuriser SSH est une étape essentielle pour protéger votre serveur contre les intrusions et les attaques. En appliquant les bonnes pratiques de durcissement, comme la mise à jour régulière d’OpenSSH, l’usage de clés SSH robustes, la restriction des accès et l’audit de votre configuration, vous réduisez considérablement les risques de compromission.

Ne négligez pas la surveillance continue et l’automatisation pour garantir une sécurité optimale sur le long terme. Un serveur bien configuré est un serveur plus sûr !