Dans un parc informatique possédant des machines linux, le SSH est quelque chose de classique. Très souvent scanné, régulièrement mal sécurisé, il s'agit aussi d'une porte d'entrée possible pour des attaques. De plus la problématique de la tracabilité du SSH pousse souvent les entreprise à mettre en place des process spécifiques.

Sur Amazon, il est possible depuis l'année dernière de se connecter en SSH sans avoir besoin de clé, de login ou de mot de passe... et sans SSH.

SSM - Systems Manager Agent : Configuration manager à la sauce Amazon

Amazon permet de déployer facilement des flottes de serveurs, cependant, déployer un serveur est aisé, le maintenir ne l'est pas forcément. Beaucoup d'entreprises feront sans doute le choix d'utiliser Ansible, Puppet, Chef ou un autre configuration manager. Toutefois, Amazon met aussi à disposition le service SSM qui permet entre autre :

  • De mettre à jour des applicatifs à distance selon des critères spécifiés (tags par exemple)
  • Audit des binaires installé sur les machines (paquets installés, version etc...)
  • Génération de rapport suite à ces audits
  • Connection distante à des machines

C'est cette dernière fonctionnalité qui nous intéresse dans cet article.

SSM - Connection sécurisée et tracée à une instance Linux

Sur AWS, par défaut, la connexion se fait à l'aide de clé publique déployée sur le serveur. Se pose alors la question de la rotation de ces clés, de leur emplacement de stockage, de qui possède la clé, du fait qu'elle peut être partagée au delà du scope initialement prévu etc...

Des solutions existent pour gérer les clés autrement, je pense notamment à BLESS de Netflix (Bastion's Lambda Ephemeral SSH Service - GitHub). Ces solutions requièrent néanmoins une complexité aussi bien sur sa mise en place que sur son MCO. En effet, la brique mise en place devient directement critique, étant nécessaire à la moindre connexion sur une machine.

Une alternative en mode service est possible au travers d'Amazon SSM. Les avantages de ce mode de connexion sont multiples :

  • Accès fédéré au travers d'AWS IAM, une policy est nécessaire pour accéder aux machines, et cette policy peut être très fine
  • Enregistrement de toutes les actions sur un fichier de log disponible sur S3, et facilement sécurisable ou centralisable
  • Plus besoin d'ouvrir le port 22 sur les machines
  • Aucune configuration/installation nécessaire si l'on est sur une machine fonctionnant avec une image Amazon Linux

SSH via SSM en action

Pour les besoin de cet article, j'ai créé une machine fonctionnant avec une Amazon Linux 2 et ayant la policy "AmazonEC2RoleforSSM" (AWS Managed Policy), cette policy est bien trop permissive pour être utilisée sur un environnement productif, mais suffisante pour ce poc. Cette machine n'a aucun port ouvert en "inbound".

Je n'ai déployé aucune clé SSH sur la machine.

J'ai au préalable configuré SSM pour qu'il log toutes les actions dans un bucket S3 :

L'utilisateur que j'utilise est lui aussi trop permissif et utilise la policy "AmazonSSMFullAccess"  (AWS Managed Policy), encore une fois, en production, on limitera autant que possible les permissions.

J'ai aussi installé sur mon PC client le package "session-manager-plugin" nécessaire pour établir la connection (documentation d'installation disponible ici).

Maintenant que tout ces prérequis sont prêt, je peux me connecter à ma machine.

Deux méthodes sont disponible :

Connexion via un Shell "classique"

Je me connecte depuis mon shell, mais au lieu de taper ssh user@ip je passe par la CLI Amazon, je fais ensuite quelques commandes pour la démo, comme on peut le voir, le comportement du shell est le même qu'en SSH, y compris avec le tab completion :

Quelques minutes après la connection, le log associé est disponible sur S3

En allant voir le log, on retrouve :

  • Les commandes que j'ai tapé
  • Les retours que j'ai eu

Connexion au travers la console SSM

Il est aussi possible de se connecter au travers la console SSM en cliquant sur "Start session" depuis l'accueil SSM

Je choisi ensuite ma machine et clique sur "Start session" une fois de plus. Il est à noter que seules les machines avec SSM installé et le rôle autorisant SSM à fonctionner sont listées ici, il peut y avoir une latence d'une à deux minutes avant qu'une machine apparaisse.

Je retape les même commandes que plus haut, une fois encore, le comportement est le même qu'un shell classique, et chose intéressante par rapport à beaucoup d'émulation de console en ligne qui sont lentes, la latence est très bonne, et l'utilisation est fluide. Une fois de plus, on peut encore utiliser le tab completion.

De la même manière que précédemment, le log est ensuite sur le bucket s3 que j'ai paramétré, et on retrouve toutes les commandes que j'ai entré.

En conclusion

SSM permet d'avoir une alternative fiable et sécurisé au SSH classique, en centralisant les accès et forçant une authentification pour accéder à la moindre ressource. De plus il permet aussi de limiter les vecteurs d'attaques, vu qu'il ne nécessite pas d'ouverture de port supplémentaire. Il permet d'avoir un filtrage fin, adapté au modèle d'Amazon (on peut par exemple donner accés à des machines portant uniquement certaines combinaisons de tag), tout en assurant une tracabilité complète des actions.

Enfin, il permet de ne plus avoir à gérer de clés SSH, ce qui implique :

  • Plus de coffre fort pour les stocker
  • Plus de rotation à mettre en place
  • Plus d'implémentation et MCO de l'utilisation de ces clés