Durcir l'accès SSH

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.

Astuce

Cette documentation s'inscrit dans la continuité de notre précédent guide destiné aux débutants, où j'avais introduit quelques pistes pour sécuriser votre serveur SSH, comme l'utilisation de Fail2ban. Si vous n'êtes pas familier avec SSH, je vous invite à commencer par ce guide pour comprendre les bases avant de passer à la sécurisation.

Pourquoi mettre à jour OpenSSH régulièrement ?

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, CVSS 8.1) a touché les versions 8.5p1 à 9.7p1 côté serveur : une condition de course dans le gestionnaire de signal permettait une exécution de code en root, sans authentification. Le correctif est 9.8p1. À nuancer : l'exploitation n'a été démontrée que sur Linux glibc 32 bits (plusieurs heures d'attaque), et OpenBSD n'est pas affecté. L'impact justifie malgré tout un patch d'urgence.

En février 2025, CVE-2025-26465 (CVSS 6.8) a visé le client ssh, pas le serveur : un serveur malveillant pouvait usurper un hôte légitime (attaque man-in-the-middle), uniquement si VerifyHostKeyDNS valait yes - ce qui n'est pas la valeur par défaut. Corrigée en 9.9p2.

Vérifier une version patchée, pas le numéro amont

Les distributions rétro-portent ces correctifs sans changer le numéro de version. Un ssh -V qui affiche « OpenSSH_9.6p1 » peut donc être déjà patché par Debian ou Ubuntu. Vérifiez l'avis de sécurité de votre distribution (apt changelog openssh-server) plutôt que le seul numéro amont.

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é.

Configuration sécurisée d’OpenSSH

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é

Ajoutez ou modifiez ces lignes dans /etc/ssh/sshd_config, puis rechargez le service après validation (voir le workflow anti-blocage plus bas).

Paramètre	Valeur recommandée	Explication
PermitRootLogin	no	Interdit la connexion directe en root (défaut OpenSSH = prohibit-password, déjà mieux que yes).
PubkeyAuthentication	yes	Active l’authentification par clé, le socle du durcissement.
PasswordAuthentication	no	Interdit le mot de passe au profit des clés (ne le posez qu’après avoir déployé et testé une clé).
KbdInteractiveAuthentication	no	Ferme l’auth interactive (clavier/PAM). C’est le nom moderne de l’ancien ChallengeResponseAuthentication (alias déprécié).
PermitEmptyPasswords	no	Refuse tout compte sans mot de passe (défaut no, on le fige).
AllowUsers / AllowGroups	alice bob	Liste blanche des comptes autorisés à se connecter : le réglage le plus efficace. Ces directives s’ajoutent.
MaxAuthTries	3	Limite les tentatives par connexion (défaut 6).
MaxSessions	2	Limite les sessions multiplexées sur une même connexion.
MaxStartups	10:30:60	Limite les connexions non authentifiées simultanées (anti-flood, réduit la fenêtre d’exploitation de regreSSHion).
LoginGraceTime	30	Délai d’authentification court : moins de connexions pendantes. Le 300 (5 min) souvent recommandé va à contre-sens du durcissement.
LogLevel	VERBOSE	Logs détaillés (empreintes de clés incluses) dans /var/log/auth.log (Debian) ou /var/log/secure (RHEL).
AllowTcpForwarding	no	Bloque le rebond TCP via SSH si le serveur n’en a pas besoin (défaut yes).
AllowAgentForwarding	no	Bloque l’agent forwarding (vecteur de rebond).
X11Forwarding	no	Désactive le transfert graphique X11, inutile sur un serveur.
PermitTunnel	no	Pas de tunnel réseau L2/L3 via SSH.
ClientAliveInterval / ClientAliveCountMax	300 / 2	Ferme les sessions inactives (ici après ~10 min sans réponse).
UsePAM	yes	Active PAM (politiques de mot de passe, verrouillage de comptes).

Glissez pour voir

Appliquer sans se verrouiller dehors

C'est l'étape où l'on se coupe l'accès si on va trop vite. Le bon réflexe en quatre temps, à ne jamais sauter :

# 1. Verifier la SYNTAXE (ne teste pas la logique d'acces)
sudo sshd -t

# 2. Verifier la config EFFECTIVE (c'est elle qui s'applique)
sudo sshd -T | grep -iE 'permitroot|passwordauth|allowusers|ciphers'

# 3. Recharger SANS couper les sessions (service "ssh" sur Debian, "sshd" sur RHEL)
sudo systemctl reload ssh

# 4. Tester dans une 2e session, en gardant la premiere ouverte
ssh utilisateur@serveur

sshd -t ne valide que la syntaxe : on peut avoir un sshd -t vert et se verrouiller quand même (un AllowUsers mal écrit, un PasswordAuthentication no sans clé déployée). D'où le sshd -T (configuration réellement appliquée) et la 2e session de test.

Ne vous enfermez pas dehors

Préférez reload à restart : reload ne tue pas votre session courante. Gardez toujours la session actuelle ouverte pendant les tests, et sur un serveur distant, un accès de secours (console KVM ou série). Une mauvaise règle SSH appliquée à l'aveugle est la première cause de serveur inaccessible.

Comprendre les drop-ins sshd_config.d/

Sur Debian 12, Ubuntu et RHEL 9, /etc/ssh/sshd_config commence par Include /etc/ssh/sshd_config.d/*.conf. Or SSH retient, pour la plupart des directives, la première valeur rencontrée. Conséquence vérifiée en lab : un fichier de sshd_config.d/ (lu en premier via l'Include en tête) l'emporte sur ce que vous écrivez plus bas dans le fichier principal.

# /etc/ssh/sshd_config.d/00-hardening.conf  ->  MaxAuthTries 9  (lu en PREMIER)
# /etc/ssh/sshd_config                       ->  MaxAuthTries 3  (ignore)
# sshd -T  =>  maxauthtries 9

Le piège classique : sur un cloud, 50-cloud-init.conf réactive souvent PasswordAuthentication yes et annule vos réglages. Deux règles d'or :

• placez vos réglages dans un fichier /etc/ssh/sshd_config.d/00-hardening.conf (le préfixe 00- gagne l'ordre lexical) ;
• vérifiez toujours le résultat avec sshd -T, jamais en relisant sshd_config.

Gestion des Ciphers et Algorithmes dans OpenSSH

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é.

Identifier et éliminer les algorithmes faibles

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

Deux principes guident le choix : ne garder que des MACs en -etm (Encrypt-Then-MAC, qui authentifie le message chiffré, plus sûr que les MACs classiques), et privilégier l'échange de clés résistant au quantique quand le serveur est assez récent. Le bloc ci-dessous converge entre Mozilla, ssh-audit et l'ANSSI, et a été validé par sshd -t sur OpenSSH 9.2 :

/etc/ssh/sshd_config.d/00-crypto.conf

KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256
RequiredRSASize 3072

sntrup761x25519-sha512@openssh.com (post-quantique) est activé par défaut depuis OpenSSH 9.0 ; sur une version plus ancienne, retirez cette entrée, sinon sshd -t échoue. RequiredRSASize 3072 refuse les clés et clés d'hôte RSA trop courtes. Avant de coller un algorithme, vérifiez qu'il est supporté par votre binaire :

ssh -Q kex ; ssh -Q cipher ; ssh -Q mac

À bannir explicitement (tous présents dans ssh -Q, donc activables par erreur) : *-cbc, arcfour*, blowfish, 3des-cbc ; diffie-hellman-group1-sha1, *-group14-sha1, *-exchange-sha1 ; hmac-md5*, hmac-sha1* et tout MAC non-ETM ; ssh-dss.

Appliquer et vérifier

Validez la syntaxe, rechargez (jamais restart à l'aveugle), puis confirmez ce qui est réellement retenu :

sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -iE 'ciphers|macs|kexalgorithms'

Attention

Il est important de tester la configuration après ces changements pour s'assurer que le serveur SSH fonctionne comme prévu et que la connectivité n'est pas affectée. En cas de problème, il est important de pouvoir revenir à la configuration précédente. Ne faites pas cela sur de la prod !

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é.

Utilisation de SSH-Audit pour sécuriser OpenSSH

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.

Installation de SSH-Audit

SSH-Audit s’installe via pipx (sur Debian/Ubuntu récents, un pip install direct échoue à cause de PEP 668, l’environnement Python système étant protégé) :

sudo apt install pipx
pipx install ssh-audit

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

Auditer un serveur SSH avec SSH-Audit

Pour analyser votre propre machine locale, utilisez simplement :

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 :

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.

Appliquer les recommandations de SSH-Audit

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.

Réutilisez le bloc crypto canonique vu plus haut (fichier /etc/ssh/sshd_config.d/00-crypto.conf avec sntrup761x25519, ciphers GCM/ChaCha20 et MACs ETM). Appliquez ensuite proprement, sans couper les sessions :

sudo sshd -t && sudo systemctl reload ssh

Relancez ssh-audit localhost : les éléments signalés en rouge doivent avoir disparu.

Un guide pratique pour chaque distribution

À 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é.

Utilisation de clés SSH robustes

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.

Choisir un type de clé sécurisé

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
RSA	Minimum 4096 bits
Ed25519	Recommandé, rapide et sécurisé
ECDSA	Déconseillé, remplacé par Ed25519
DSA	Obsolète, à éviter

Glissez pour voir

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

Génération d’une clé SSH sécurisée

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

• **Génération d'une clé Ed25519 :

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "mon-utilisateur@serveur"

• **Génération d'une clé RSA (4096 bits) :

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -C "mon-utilisateur@serveur"

Sécurisation de la clé privée

• 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 :

  chmod 600 ~/.ssh/id_ed25519
  chmod 600 ~/.ssh/id_rsa

Ajout de la clé sur un serveur

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 :

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 :

cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Vérification et connexion avec la clé

Testez la connexion en spécifiant votre clé :

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

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.

Surveillance de l’activité SSH

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 :

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

Gestion des clés SSH

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 :

  cat ~/.ssh/authorized_keys

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.

Pour aller plus loin

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

• Authentification : Approfondissez la configuration PAM pour renforcer l'authentification.
• Audit de sécurité : Vérifiez vos configurations avec Lynis ou OpenSCAP.
• Référentiels : Appliquez les recommandations ANSSI-BP-028 ou les CIS Benchmarks.
• Contrôle d'accès obligatoire : Implémentez SELinux ou AppArmor pour confiner le service SSH.
• Automatisation : Gérez vos configurations avec Rudder ou Ansible.

Conclusion

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 !

×

📖 Voir la documentation →