Pourquoi la sécurité SSH mérite une approche structurée
SSH reste l’un des outils les plus importants pour administrer les serveurs Linux et Unix. C’est aussi l’une des voies les plus attractives pour un attaquant. Une clé privée volée, un mot de passe exposé, un service SSH non corrigé ou un compte administrateur doté de privilèges excessifs peuvent fournir un accès direct à des systèmes sensibles.
Sécuriser l’accès à un serveur ne consiste pas à modifier un seul paramètre dans sshd_config. Le renforcement de SSH est efficace lorsque l’identité, l’accès réseau, les autorisations du système d’exploitation, la surveillance et les contrôles de reprise fonctionnent ensemble. Une clé robuste est utile, mais elle ne compense pas une clé laissée sur un ordinateur portable non géré. Une liste d’adresses IP autorisées réduit l’exposition, mais n’empêche pas une utilisation abusive depuis un réseau approuvé.
L’objectif est de rendre les accès non autorisés difficiles, de limiter ce qu’un compte compromis peut faire, de détecter rapidement les activités suspectes et de conserver une voie sûre pour l’administration légitime pendant un incident.
Commencer par les deux mesures de renforcement SSH les plus importantes
Désactiver la connexion directe de root
La connexion directe de root complique la traçabilité et le confinement. Tous les administrateurs apparaissent comme le même utilisateur et une connexion réussie dispose immédiatement de privilèges illimités. Définissez PermitRootLogin no lorsque cela est compatible avec vos opérations, puis exigez que les administrateurs se connectent avec des comptes nominatifs et utilisent sudo pour les actions privilégiées.
Des exceptions peuvent exister pour des procédures de récupération soigneusement conçues, mais elles doivent être délibérées et non constituer la configuration par défaut. Si une plateforme nécessite une voie d’urgence au niveau root, protégez-la avec une clé distincte, un réseau source restreint, une surveillance renforcée et un processus d’approbation documenté.
Désactiver l’authentification par mot de passe
L’authentification par mot de passe est exposée aux attaques par devinette, au credential stuffing, à l’hameçonnage et à la réutilisation des mots de passe. Sur les serveurs qui le permettent, désactivez-la avec PasswordAuthentication no après avoir confirmé que l’accès approuvé par clé fonctionne. Vérifiez également les paramètres associés, comme l’authentification interactive au clavier, car certaines configurations peuvent encore autoriser une connexion de type mot de passe par cette méthode.
N’effectuez pas cette modification sans tester une session administrative active et une nouvelle session distincte. Une erreur opérationnelle courante consiste à fermer l’unique connexion fonctionnelle avant de vérifier la méthode d’accès de remplacement. Conservez une console contrôlée ou une voie de récupération hors bande pour les changements susceptibles de bloquer l’équipe.
Utiliser correctement une authentification forte par clé publique
L’authentification par clé publique est généralement plus sûre et plus facile à gérer que les mots de passe, mais la sécurité du système dépend des deux parties de la paire de clés. La clé publique doit être placée dans la configuration des clés autorisées du serveur. La clé privée doit rester secrète et ne doit jamais être copiée dans des tickets, des scripts, des lecteurs partagés ou des messages de discussion.
Privilégiez les types de clés modernes pris en charge par le système d’exploitation et la version d’OpenSSH utilisés. Les clés de sécurité protégées par du matériel peuvent offrir une protection particulièrement forte, car l’opération avec la clé privée se déroule sur l’appareil et la clé est plus difficile à extraire. Lorsque ces clés ne sont pas pratiques, utilisez une phrase secrète robuste et stockez les clés privées dans un magasin de clés chiffré du système d’exploitation ou dans un système reconnu de gestion des secrets.
Chaque administrateur doit disposer d’une clé individuelle plutôt que de partager une clé d’équipe. Les clés individuelles permettent d’identifier la personne responsable d’une connexion, de supprimer l’accès d’une personne sans affecter les autres et d’examiner l’âge et l’objectif de chaque identifiant. Le commentaire associé à une clé publique n’est pas un contrôle de sécurité, mais des commentaires pertinents peuvent aider à expliquer le propriétaire et les dates d’expiration lors d’un audit.
Protéger la clé privée
Une clé privée sans phrase secrète est, en pratique, un identifiant de possession réutilisable. Si un ordinateur portable est volé ou si un logiciel malveillant lit le fichier de clé, un attaquant peut être en mesure de se connecter immédiatement. Utilisez une phrase secrète forte et unique et chargez les clés dans un agent uniquement pendant la durée nécessaire. Sécurisez le poste de travail avec un chiffrement intégral du disque, un verrouillage de l’écran, les mises à jour prises en charge du système d’exploitation et une protection des terminaux.
Limitez les autorisations des fichiers contenant les clés privées. Sur les systèmes de type Unix, une clé ne devrait normalement être lisible que par son propriétaire. Les sauvegardes des clés privées exigent le même niveau de protection que les originaux ; une copie non chiffrée dans un dépôt de sauvegarde compromet la protection de l’appareil utilisé. Lorsqu’un administrateur quitte l’entreprise, perd un appareil ou suspecte une compromission, considérez la clé privée comme compromise jusqu’à sa révocation ou sa suppression de tous les serveurs autorisés.
Appliquer le principe du moindre privilège et séparer les identités administratives
L’accès SSH doit donner uniquement l’autorité nécessaire au rôle de chacun. Un développeur web peut avoir besoin de consulter les journaux d’application et de redémarrer un service, tandis qu’un ingénieur système peut nécessiter des privilèges plus larges sur le système d’exploitation. Ces responsabilités ne doivent pas automatiquement conduire à un accès root illimité.
Utilisez des comptes nominatifs et des règles sudo contrôlées pour autoriser des commandes précises lorsque cela est possible. Vérifiez si certaines commandes peuvent être combinées pour échapper aux restrictions. Par exemple, l’autorisation d’exécuter en tant que root un éditeur, un interpréteur ou un utilitaire de sauvegarde peut en réalité fournir un accès illimité. Une conception fondée sur le moindre privilège doit tenir compte de l’impact pratique de chaque commande autorisée, et pas seulement de son nom.
Séparez l’administration quotidienne des activités à haut risque. Un administrateur peut utiliser un compte standard pour ses e-mails, sa navigation et ses tâches courantes, puis utiliser un compte privilégié distinct uniquement lorsque cela est nécessaire. Cela réduit le risque qu’une attaque d’hameçonnage ou une compromission du navigateur hérite immédiatement des droits d’administration des serveurs. Cela crée également des journaux plus clairs et facilite l’examen des activités privilégiées.
Les comptes de service ne doivent pas servir à l’administration interactive. Donnez à l’automatisation sa propre identité, sa propre clé et ses propres autorisations, puis limitez-la aux hôtes et aux commandes nécessaires. Un compte de déploiement ne doit pas également être utilisé pour la maintenance des bases de données ou la récupération d’urgence.
Choisir le bon second facteur et la bonne frontière réseau
MFA pour SSH
L’authentification multifacteur peut réduire l’impact d’une clé privée volée, en particulier lorsque le second facteur est indépendant du poste de travail de l’administrateur. Les approches courantes comprennent l’intégration de SSH à un système de mots de passe à usage unique, un défi fondé sur PAM, un fournisseur d’identité central ou un bastion qui impose la MFA avant d’autoriser l’accès aux systèmes suivants.
La conception de la MFA comporte des compromis. Un code à usage unique généré sur le même ordinateur portable compromis que la clé SSH peut fournir moins de protection qu’un jeton matériel distinct. Un service d’authentification central peut améliorer le contrôle, mais introduit une dépendance qui doit être surveillée et prise en charge en cas de panne. Certaines automatisations ne peuvent pas répondre à un défi MFA interactif ; les tâches non interactives nécessitent donc une conception différente, plutôt qu’une désactivation permanente de la MFA sur un compte puissant.
Lorsque cela est pris en charge, les clés de sécurité SSH FIDO2 ou similaires protégées par du matériel peuvent offrir une forte résistance à l’hameçonnage. Testez leur compatibilité avec le client, le système d’exploitation et le processus de récupération choisis avant de les rendre obligatoires. Prévoyez une procédure contrôlée pour remplacer un jeton perdu sans laisser de porte dérobée permanente et cachée.
Listes d’adresses IP autorisées, VPN et bastions
Limiter SSH à des adresses IP sources connues peut réduire les scans et les attaques opportunistes. Un pare-feu, un groupe de sécurité ou une liste de contrôle d’accès réseau peut autoriser le port 22 uniquement depuis une plage de bureaux, un réseau d’administration ou un VPN. Cette mesure est utile, mais elle ne constitue pas une protection complète : les réseaux approuvés peuvent être compromis, les adresses peuvent changer et un attaquant peut déjà se trouver dans l’environnement autorisé.
Un VPN crée une frontière administrative distincte et peut faciliter la gestion des règles de pare-feu. Il doit néanmoins être corrigé, fortement authentifié et surveillé. Un bastion, parfois appelé jump host, concentre les accès administratifs dans un système contrôlé. Il peut imposer la MFA, enregistrer les sessions et fournir un point unique pour les listes d’autorisation et la journalisation. Il devient aussi une cible de grande valeur et nécessite donc une configuration renforcée, peu de logiciels, des correctifs rapides et une voie de récupération testée.
N’exposez pas largement SSH à Internet simplement parce que l’authentification par clé est activée. De même, ne considérez pas le déplacement de SSH vers un autre port comme une mesure de sécurité. Un port non standard peut réduire le bruit, mais il ne remplace ni l’authentification, ni l’application des correctifs, ni les restrictions réseau, ni la surveillance.
Comprendre les risques de la redirection de l’agent SSH
La redirection de l’agent SSH est pratique lorsqu’un administrateur se connecte à un serveur, puis doit en atteindre un autre sans copier de clé privée. L’hôte distant peut demander à l’agent local d’effectuer une opération d’authentification. La clé privée elle-même n’est pas transférée, mais un serveur distant compromis peut être capable d’utiliser l’agent redirigé tant que la connexion est active.
Ce risque est important lorsque vous vous connectez via des serveurs moins fiables que la destination. Évitez d’activer la redirection d’un agent par défaut. Utilisez-la uniquement pour une tâche précise et comprise, et envisagez plutôt des contraintes de destination, des clés séparées ou une architecture avec bastion. Les administrateurs doivent savoir quels hôtes peuvent atteindre leur agent et fermer rapidement les sessions redirigées.
Pour l’automatisation, privilégiez les identifiants à durée de vie courte, les clés de déploiement aux autorisations limitées, l’identité des charges de travail ou un gestionnaire de secrets lorsque la plateforme le permet. Ne placez jamais une clé privée d’administrateur à longue durée dans un dépôt de code source ou une image de build. Si un pipeline doit utiliser SSH, limitez si possible la clé par source, commande et destination, puis déclenchez une alerte en cas d’utilisation inattendue.
Faire tourner, révoquer et examiner les accès avec méthode
La rotation des clés n’est pas une simple tâche annuelle inscrite au calendrier. Établissez un inventaire indiquant pour chaque clé son propriétaire, son objectif, les systèmes concernés, sa date de création, sa dernière utilisation et sa date d’expiration prévue. Supprimez les clés inutilisées de authorized_keys et des systèmes centraux d’accès. Une clé dont le propriétaire est inconnu doit être considérée comme un risque d’accès, et non comme un élément de configuration historique inoffensif.
La révocation doit être réalisable sous pression. Documentez comment supprimer une clé des serveurs individuels, de la gestion de configuration, des bastions et des plans de contrôle cloud. Si des certificats ou une autorité de certification SSH centrale sont utilisés, définissez des durées de vie courtes et maintenez un processus de révocation fiable. Vérifiez que la révocation d’un administrateur ne supprime pas accidentellement l’accès nécessaire à l’équipe de réponse aux incidents.
Effectuez une revue des accès après les changements de personnel, les changements de fournisseurs, les grands projets d’infrastructure et les incidents de sécurité. Vérifiez notamment :
- Les paramètres de connexion directe de root et d’authentification par mot de passe.
- Les comptes utilisateurs inconnus, partagés ou inactifs.
- Les clés publiques sans propriétaire, obsolètes ou dépourvues de date d’expiration ou de revue.
- Les autorisations sudo trop larges et les commandes autorisées à risque.
- Les comptes de service qui autorisent la connexion interactive.
- Les interfaces d’écoute, règles de pare-feu ou expositions SSH publiques inattendues.
- Les appartenances au VPN, au bastion et à la MFA, y compris les comptes dormants.
- La redirection d’agent, la redirection de ports et les autres fonctions SSH inutiles.
- La couverture des journaux, la synchronisation de l’horloge et la conservation des événements d’authentification.
Pour obtenir une liste de contrôle pratique, comparez votre configuration actuelle aux bonnes pratiques actuelles de renforcement des serveurs SSH, puis validez chaque recommandation par rapport à votre modèle opérationnel. Les conseils génériques ne peuvent pas déterminer quelles exceptions d’urgence votre entreprise doit réellement conserver.
Corriger le service et rendre les accès suspects visibles
SSH fait partie du système d’exploitation et doit suivre la même discipline de mise à jour que le reste du serveur. Appliquez les mises à jour de sécurité à l’implémentation SSH, au système d’exploitation, aux bibliothèques, au VPN, au bastion et aux outils d’administration. Donnez la priorité aux systèmes exposés à Internet et définissez comment les mises à jour urgentes sont testées et déployées sans laisser une exposition critique sans traitement.
Activez la journalisation des connexions et des authentifications à un niveau permettant les investigations sans générer un bruit ingérable. Enregistrez les connexions réussies et échouées, les adresses sources, les noms d’utilisateur, l’identité de la clé ou du certificat lorsqu’elle est disponible, l’élévation de privilèges et les modifications de la configuration d’authentification. Envoyez les journaux importants vers un système séparé afin qu’un attaquant ayant obtenu l’accès au serveur ne puisse pas effacer discrètement les preuves.
Les alertes doivent se concentrer sur des signaux utiles. Il peut s’agir de nombreux échecs visant un compte valide, d’une connexion réussie depuis un pays ou un réseau inhabituel, d’une nouvelle clé publique, d’une activité au niveau root en dehors d’une fenêtre de maintenance, de la désactivation d’un service de journalisation ou d’une modification soudaine des règles de pare-feu. Les alertes doivent avoir un responsable et une voie d’escalade ; un flux illisible de notifications peu pertinentes offre une protection limitée.
La limitation du débit et les outils qui bloquent temporairement les échecs répétés peuvent réduire le bruit et la consommation de ressources liés aux attaques par force brute. Ils peuvent aussi bloquer des utilisateurs légitimes derrière des adresses partagées ou ne pas arrêter une attaque lente et distribuée. Utilisez-les comme une couche parmi d’autres, avec une authentification forte, des contrôles réseau, une surveillance et un processus de réponse testé.
Sécuriser l’automatisation et les accès d’urgence
L’automatisation a souvent besoin d’un accès SSH sans présence humaine, ce qui rend la rigueur de conception particulièrement importante. Créez un compte dédié pour chaque flux de travail significatif. Limitez son environnement source, ses hôtes de destination et ses commandes autorisées. Stockez son identifiant dans un coffre de secrets contrôlé ou sur un exécuteur protégé, limitez sa durée de vie lorsque cela est possible et empêchez les journaux de build d’afficher les clés privées ou les détails de connexion.
Vérifiez si la tâche a réellement besoin de SSH. Une plateforme de déploiement, un système de gestion de configuration ou une API de fournisseur peut offrir des autorisations plus précises et une meilleure traçabilité. Lorsque SSH est nécessaire, séparez les identifiants de production de ceux du développement et exigez une approbation explicite pour les changements en production.
L’accès d’urgence doit être disponible, mais rare. Conservez un compte ou un accès console de secours documenté sous une gestion contrôlée, avec une authentification forte, un nombre limité d’utilisateurs et des exigences d’approbation claires. Surveillez chaque utilisation et examinez-la ensuite. Testez la procédure avant une panne ; un compte d’urgence qui n’a jamais été utilisé peut échouer à cause d’une clé expirée, d’une route réseau modifiée ou d’une dépendance oubliée.
Ne renforcez pas la résilience en conservant une porte dérobée permanente et sans restriction. La voie de récupération doit être protégée plus soigneusement que l’accès courant, avec des informations de récupération hors ligne ou contrôlées séparément lorsque cela est pertinent.
Adapter les contrôles SSH au serveur que vous contrôlez réellement
Le niveau de renforcement SSH disponible dépend du modèle d’hébergement. Avec un VPS ou un serveur dédié géré par l’entreprise, le client contrôle généralement le système d’exploitation, la configuration du démon SSH, les règles de pare-feu, les comptes utilisateurs, les clés, les correctifs et la journalisation. La responsabilité exacte peut être partagée avec un fournisseur géré ; confirmez donc qui effectue les changements et qui répond aux alertes.
Sur un hébergement mutualisé, les clients ne contrôlent généralement pas la configuration SSH globale du serveur. L’hébergeur décide si SSH est disponible, quelles méthodes d’authentification sont prises en charge, si l’accès shell est restreint et comment le système sous-jacent est corrigé. Un client peut parfois téléverser une clé ou utiliser un shell limité, mais ne peut normalement pas désactiver la connexion root, modifier sshd_config ou imposer des politiques d’accès à l’échelle de l’organisation. La distinction entre une infrastructure VPS gérée par le client et un environnement d’hébergement mutualisé est donc importante : les contrôles SSH dépendent de l’opérateur du serveur.
Ne supposez pas qu’une offre d’hébergement mutualisé fournit les mêmes contrôles administratifs qu’un VPS ou un serveur dédié. Si l’entreprise a besoin d’un accès au système d’exploitation, de comptes administrateurs nominatifs, de règles de pare-feu personnalisées, d’un bastion, d’une journalisation SSH détaillée ou de contrôles de sauvegarde au niveau serveur, choisissez un modèle d’infrastructure où ces responsabilités sont clairement attribuées.
Relier la sécurité des accès à la reprise
Des contrôles SSH solides réduisent la probabilité d’une administration non autorisée, mais ils ne peuvent pas garantir qu’un compte, un serveur ou un poste d’administration ne sera jamais compromis. La planification de la reprise doit partir du principe que les identifiants peuvent être volés et qu’un attaquant peut modifier ou chiffrer les données.
Pour les serveurs contrôlés par le client, Safenix fournit une sauvegarde hors site conçue pour la reprise des serveurs d’entreprise. Les données de sauvegarde sont chiffrées avec une clé que Safenix ne détient jamais, stockées en Allemagne et immuables pendant la durée de la fenêtre de conservation sélectionnée. Cette séparation est importante : l’accès au serveur de production ne doit pas automatiquement permettre de réécrire toutes les sauvegardes protégées.
Les sauvegardes ne remplacent pas le renforcement de SSH, et le renforcement de SSH ne remplace pas les sauvegardes. Vérifiez que les identifiants de sauvegarde sont séparés des comptes administrateurs courants, que le processus de sauvegarde ne peut pas être désactivé facilement depuis une session compromise et que l’accès à la récupération est documenté. Testez la restauration, et pas uniquement la réussite des sauvegardes, puis indiquez qui peut approuver et effectuer une récupération.
Un cycle de revue pratique pour les agences et les équipes IT
Intégrez la sécurité SSH à l’administration normale plutôt que de la traiter comme un nettoyage ponctuel. Un cycle de revue utile peut comprendre une vérification mensuelle des connexions échouées et inhabituelles, une revue trimestrielle des comptes, des clés et des privilèges, ainsi qu’une revue déclenchée par les événements après des changements de personnel, des migrations d’infrastructure ou une compromission présumée.
- Inventoriez chaque serveur, point d’accès SSH, administrateur, identité d’automatisation et voie d’urgence.
- Confirmez le propriétaire et l’objectif métier de chaque compte et de chaque clé publique.
- Validez les paramètres de connexion root et par mot de passe, la MFA, les frontières réseau et les options de redirection.
- Examinez les règles sudo, les autorisations des comptes de service et l’automatisation de production.
- Vérifiez l’état des correctifs, la journalisation, le routage des alertes et la synchronisation de l’heure.
- Testez la révocation des clés, l’accès de secours, l’isolation des sauvegardes et la restauration.
- Documentez les exceptions avec un responsable, une justification, une date d’expiration et des contrôles compensatoires.
Les meilleurs résultats viennent de la combinaison de contrôles simples et vérifiables : des identités nominatives plutôt que des comptes partagés, des clés plutôt que des mots de passe, le moindre privilège plutôt qu’un accès root permanent, des réseaux restreints plutôt qu’une exposition ouverte et une récupération testée plutôt que l’espoir. Cette approche rend l’accès sécurisé aux serveurs plus résilient sans prétendre qu’un seul paramètre SSH puisse éliminer le risque.