1. Introduction
L’adoption croissante du cloud computing et des pratiques modernes de DevOps a donné naissance à une tendance significative : le “No SSH”. Cette approche vise à limiter, voire à éliminer, l’utilisation du protocole SSH pour accéder aux infrastructures cloud. En optant pour une gestion sans SSH, les équipes modernisent leurs opérations tout en renforçant la sécurité et l’automatisation. Cet article explore les raisons et les bénéfices de cette évolution suivis de quelques exemples pratiques.
2. Le problème de SSH dans les environnements cloud
SSH a longtemps été l’un des principaux moyens d’administrer des serveurs. Cependant, son utilisation comporte certains inconvénients:
- Sécurité : Les accès SSH peuvent être exposés à des attaques, notamment les attaques par brute-force. On se souvient par exemple de l’alerte CERTFR-2024-ALE-009 concernant OpenSSH qui exposait une vulnérabilité permettant à un attaquant non authentifié d’exécuter du code arbitraire à distance avec les privilèges root.
- Erreurs humaines : Les connexions SSH manuelles nécessitent des configurations spécifiques sur chaque machine et peuvent facilement conduire à des erreurs voire à des fuites ou des pertes de clés privées.
- Limites en scalabilité : À grande échelle, gérer des connexions SSH individuelles (liste d’adresses IP, clé privées…) devient complexe et difficilement automatisable.
Avec ces défis à l’esprit, la tendance “No SSH” vise à limiter l’accès manuel aux serveurs pour privilégier une gestion automatisée et centralisée.
3. Les Bénéfices de l’Approche “No SSH”
L’approche “No SSH” présente plusieurs avantages dans un contexte cloud et DevOps.
Sécurité Accrue
En éliminant SSH, on réduit une surface d’attaque importante. SSH requiert l’utilisation de ports spécifiques et des clés d’accès qui, si elles sont mal gérées, peuvent exposer les systèmes à des risques de piratage. Les solutions “No SSH” préfèrent des alternatives sécurisées, comme les API sécurisées, les accès temporaires via des systèmes de bastion, et les outils de gestion centralisée des identités. Ainsi, il n’est plus nécessaire de garder ouvert le port 22 ou de gérer une liste d’adresses IP à autoriser.
GitOps et Gestion par API
GitOps, encourage à versionner toute l’infrastructure dans un dépôt Git et à utiliser des pipelines d’automatisation pour appliquer les changements. Le résultat : une infrastructure cohérente et contrôlée. Grâce à des APIs, les changements peuvent être appliqués directement à partir des pipelines de déploiement, garantissant une gestion précise et évitant les interventions manuelles. SSH n’est plus nécessaire pour opérer les ajustements ou surveiller l’état des ressources cloud.
Accès Temporaire via des Bastions Automatisés
Dans certains cas, il peut être nécessaire d’accéder directement à un serveur. Plutôt que d’ouvrir l’accès SSH en permanence, certaines entreprises utilisent des solutions de bastion temporaires, configurées pour expirer automatiquement. Par exemple, AWS Systems Manager (SSM) permet aux utilisateurs d’accéder aux instances EC2 sans SSH. Cette approche minimise les risques tout en offrant un contrôle sécurisé.
4. Comment Adopter le “No SSH” ?
Adopter le “No SSH” nécessite une transition vers des pratiques modernes de gestion et d’automatisation. Voici quelques étapes clés pour intégrer cette approche :
Intégrer les APIs pour la gestion : Utilisez les APIs fournies par les plateformes cloud pour interagir avec vos ressources. Des actions comme le redémarrage des instances, la mise à jour des configurations ou l’application de correctifs peuvent être faites via des scripts ou des pipelines CI/CD.
Éviter SSH sauf en cas de besoin : Configurez des systèmes de bastion pour les cas d’accès exceptionnel, et appliquez des règles d’expiration automatique. AWS SSM, par exemple, est une alternative sécurisée qui supprime le besoin de ports SSH ouverts.
5. Exemple pratique: Connexion à une instance EC2 sans SSH avec AWS SSM
Il s’agit d’un petit exercice pratique pour se connecter à une instance EC2 avec SSM. Pour cela il faudra :
- Une instance compatible avec SSM. Les AMI Amazon Linux ont l’agent SSM préinstallé.
- tCréer les endpoints VPC suivants :
- ec2messages.region.amazonaws.com
- ssm.region.amazonaws.com
- ssmmessages.region.amazonaws.com
- Disposer d’un subnet privé
- Activer la résolution DNS sur le VPC
- Un rôle IAM attaché à l’instance EC2 pour autoriser les échanges avec SSM
Création des endpoints VPC
Ces endpoint permettent de réaliser les opérations API depuis Systems Manager Agent. La documentation de ces opérations API est disponible ici
Ci dessous les étapes de création du endpoint ec2messages.region.amazonaws.com.
Il faudra répéter l’opération pour les deux autres et attendre qu’ils soient disponibles.
Le security group sélectionné doit autoriser HTTPS depuis le réseau du VPC.
Création du role pour l’instance EC2
Le rôle associé à l’instance doit avoir pour permissions minimales la policy AmazonSSMManagedInstanceCore qui permet la communication avec le service SSM.
Création de l’instance EC2
L’instance est créée à partir de l’AMI Amazon Linux 2023 sur laquelle est déjà installé l’agent SSM. Au choix de la paire de clé ssh, on sélectionne bien le déploiement sans clé. Il faut également veiller à ce que l’instance démarre dans le bon VPC et sur un Subnet privé.
Accès à la machine via SSM
Une fois l’instance démarrée il faut cliquer sur le bouton connect puis dans l’onglet Session Manager cliquer à nouveau sur connect.
La session démarre et ça y est vous êtes connecté sans le moindre accès SSH !
Conclusion
Le “No SSH” devient de plus en plus populaire, car il combine les avantages de la sécurité et de l’automatisation. Avec la croissance du cloud computing et des pratiques DevOps, les entreprises peuvent gérer leurs infrastructures à grande échelle sans les risques et les inconvénients des accès SSH traditionnels. En adoptant cette approche, les équipes IT peuvent optimiser la sécurité, la résilience et la rapidité de leurs déploiements tout en s’alignant sur les meilleures pratiques de gestion moderne.