On continue dans la série des différentes méthodes pour se connecter à une instance EC2 grâce au service AWS Systems Manager (SSM) – Session Manager. À l’image de EC2 Instance Connect, cette méthode nous dispense l’utilisation, et donc la gestion, de clés SSH et rend encore plus accessible la gestion de flotte d’instances.

Qu’est-ce que AWS SSM – Session Manager ?

Session Manager est un service d’AWS System manager qui permet une gestion sécurisée et traçable des instances sans nécessiter l’ouverture de ports entrants, la gestion d’hôtes bastion ou l’utilisation de clés SSH. Il permet de se conformer aux politiques d’entreprise en assurant un accès contrôlé aux instances gérées, en appliquant des pratiques de sécurité strictes et en fournissant des journaux d’audit détaillés pour chaque session. De plus, il offre aux utilisateurs finaux un accès multiplateforme en un seul clic à ces instances gérées, via le console AWS ou en CLI. Enfin, il peut tout à fait être utilisé dans un environnement hybride ou multi-cloud et offrir une gestion centralisée de toutes les machines en un seul point.

Les étapes pour utiliser AWS SSM – Session Manager

Configurer un rôle IAM

Configurer un rôle IAM pour le service EC2 avec la politique “AmazonSSMManagedInstanceCore”. Cela permet à SSM Session Manager d’établir une communication sécurisée avec l’instance EC2 via l’API SSM (utilisant des websockets). L’instance doit donc être autorisée à échanger des données avec le service.

Appliquer le rôle IAM à l’instance EC2

Que ce soit lors de sa création ou sur une instance déjà en cours d’exécution. Il est possible d’utiliser SSM Session Manager sur des instances existantes en ajoutant simplement les autorisations via le rôle IAM et en suivant les étapes nécessaires.

Si vous travaillez déjà avec une flotte d’instance et que vous souhaitez les configurer pour l’utilisation de session manager, le plus simple est d’utiliser le service “Quick Setup” de SSM.

Pour ce faire, rendez-vous dans SSM – Quick Setup et créez une nouvelle configuration de type “Host Management”.

Deuxième partie de la série AWS : Connexion à une instance EC2 avec EC2 Instance Connect

Je suis ravi de vous présenter la deuxième partie de notre série sur la connexion à une instance EC2, où nous allons explorer la méthode utilisant “EC2 Instance Connect”. Dans cet article, nous découvrirons comment se connecter à une instance sans avoir besoin de stocker des clés SSH.

Qu’est-ce que EC2 Instance Connect ?

Dans le précédent article nous avons vu comment se connecter à une instance de manière classique en SSH. Pratique et rapide pour se connecter à une instance, mais dans le cloud il n’est pas rare d’avoir tout une flotte d’instances à gouverner et la gestion du cycle de vie des clés SSH peut devenir un réel casse-tête.

Instance Connect est un service proposé par AWS qui permet de se connecter à une instance EC2 sans avoir à gérer des clés SSH. AWS génère et manage automatiquement des clés SSH temporaires pour vous, simplifiant ainsi le processus de connexion sécurisée à vos instances.

Comment EC2 Instance Connect fonctionne

Lorsque la fonction EC2 Instance Connect est activée sur une instance, le démon SSH (sshd) de cette instance est configuré avec un script AuthorizedKeysCommand personnalisé. Ce script met à jour AuthorizedKeysCommand pour lire les clés publiques SSH à partir des métadonnées de l’instance pendant le processus d’authentification SSH, et vous connecte à l’instance.

Les clés publiques SSH ne peuvent être utilisées qu’une seule fois pendant 60 secondes dans les métadonnées de l’instance. Pour vous connecter à l’instance avec succès, vous devez vous connecter à l’aide de SSH pendant cette période. Comme les clés expirent, il n’est pas nécessaire de suivre ou de gérer ces clés directement, comme vous le faisiez auparavant.

Comment utiliser EC2 Instance Connect

Créer une instance sans clés SSH

Le fait de ne pas associer de clés SSH n’est pas obligatoire, Instance Connect fonctionnera tout aussi bien. Mais dans le but de ne plus avoir à se soucier du cycle de vie des clés SSH, dans cet exemple nous n’utilisons pas de clés.

Assurez-vous de lui associer une IP publique !

Instance Connect est installé par défaut sur les AMI suivante:

• Amazon Linux 2 2.0.20190618 or later
• Ubuntu 20.04 or later

Si votre AMI ne fait pas partie de cette liste, voici un article qui explique comment l’installer sur tous types d’instances.

Ouvrir le port SSH sur le range AWS

Assurez-vous d’ouvrir le port SSH (par défaut, le port 22) dans le groupe de sécurité associé à votre instance, avec comme source le range d’IPs d’AWS, pour le trafic entrant (inbound).

Vous trouverez la liste des ranges IPs d’AWS ici. Elles sont classées par région et par service.

Pour vous aider à déterminer celle qui vous sied, vous pouvez télécharger cette liste et lancer la commande suivante:

Windows

Get-AWSPublicIpAddressRange -Region us-east-1 -ServiceKey EC2_INSTANCE_CONNECT | select IpPrefix

Linux

jq -r ‘.prefixes[] | select(.region==”us-east-1″) | select(.service==”EC2_INSTANCE_CONNECT”) | .ip_prefix’ < ip-ranges.json

Assurez-vous de modifier la région en lien avec la région sur laquelle est déployé votre instance.

Pour plus de détails voir cet article.

Configurer les droits IAM

Pour utiliser Instance Connect, vous devez configurer les autorisations IAM appropriées.

L’utilisateur IAM doit être en mesure de pouvoir transmettre ses clés SSH à EC2 Instance Connect.

Exemple de policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2-instance-connect:SendSSHPublicKey"
            ],
            "Resource": [
                "arn:aws:ec2:$REGION:$ACCOUNTID:instance/*"
            ],
            "Condition": {
                "StringEquals": {
                    "ec2:osuser": "ec2-user"
                }
            }
        }
    ]
}

Une fois cette policy créé, vous pouvez directement l’assigner à un utilisateur, un group ou un rôle qui sera assumé pour l’utilisateur IAM.

Se connecter depuis la console ou un terminal

Une fois les étapes précédentes terminées, vous êtes prêt à vous connecter à votre instance EC2 à l’aide d’Instance Connect. Vous pouvez le faire

Directement depuis la console AWS en sélectionnant l’instance puis “Connect” puis “EC2 Instance Connect”

• En utilisant un terminal SSH avec la commande

aws ec2-instance-connect send-ssh-public-key

Concernant le username, je vous renvoie sur le précédent article de cette série où je liste les username par défaut en fonction des AMI utilisées.

AWS Connexion à une instance EC2 – Partie 1: Les Clés SSH

Avec EC2 Instance Connect, la gestion des clés SSH devient plus simple et plus sécurisée, puisque celles-ci sont générées et gérées par AWS de manière éphémère. Vous pouvez ainsi vous concentrer sur votre travail et éviter les tracas liés à la gestion des clés SSH.

Ces informations sont correctes au moment de la rédaction de l’article, cependant, il est important de noter que les services AWS évoluent constamment. Il est possible que certaines fonctionnalités, noms, etc. soient différents ou aient changé depuis lors.

Étape 1 : Créer une instance EC2

Pour cette méthode, la première chose à faire consiste bien souvent à générer la paire de clés SSH qui va nous servir pour la connexion. Mais dans notre cas, AWS s’occupe de tout, donc nous pouvons tout de suite passer à la création de l’instance.

Lors de cette étape, il faudra sélectionner une paire de clés SSH, soit en choisissant une nouvelle paire générée par AWS, soit en utilisant une paire déjà existante, hébergée sur AWS.

Petit aparté : même si depuis la console de management il n’est plus possible d’ajouter des clés SSH, en vous connectant sur votre instance vous pourrez toujours en ajouter/retirer en allant voir dans le dossier “~/.ssh/authorized_keys”, comme vous le feriez sur n’importe quelle machine. Mais ce n’est pas le sujet d’aujourd’hui.

Étape 2 : IP publique

Afin de pouvoir atteindre votre instance depuis le réseau internet, il vous faudra déployer votre instance dans un subnet (sous-réseau) publique et lui associer une IP publique.

Étape 3 : Autoriser la connexion SSH

Avant toute chose revenons sur la notion de “security group”. Ces derniers sont en quelque sorte des firewalls logiciel qui par défaut bloque tout le trafic. Pour le configurer il faut choisir le port ou protocole que l’on souhaite ouvrir, la source (plage d’IPs) et ça pour le trafic entrant “inbound” et sortant “outbound” de votre instance.

Sachant que lorsque rien n’est spécifier, le trafic est bloqué, il faut ouvrir le port 22 – SSH – pour le trafic entrant (inbound). Concernant la source, les bonnes pratiques sont de limiter la plage d’IPs au maximum. Nous vous conseillons donc de mettre votre IP, ou le range de votre entreprise.

Étape 4 : Connexion

Une dernière étape est nécessaire si vous utilisez une paire de clés fraîchement générée, il faut changer les permissions sur votre clé locale afin de s’assurer qu’elle ne soit pas publiquement visible. Pour se faire lancer la commande :

chmod 400 <path/to/key.pem>

Enfin, récupérer l’IP publique ou le DNS de la machine depuis la console de management, et lancer la connexion depuis votre client SSH préféré.

ssh -i “<path/to/key.pem>” @ip

Le “user” dépend de l’AMI utilisé pour lancer l’instance. Voici un tableau des principaux utilisateurs par défaut:

Bonus tip

Tout ça s’est bien joli mais si la machine n’est pas exposée sur internet, elle est sur un réseau privé et n’a donc pas d’adresse IP, est-il quand-même possible de se connecter en SSH dessus ?

Bien entendu !

Une des techniques est d’utiliser une instance relai, généralement appelée “Bastion”. Cette dernière doit être déployée sur le même VPC que le machine que l’on souhaite atteindre, mais dans un subnet publique (configuré avec une internet gateway), afin de pouvoir lui attribuer une IP publique.

D’une part, créez votre bastion en suivant les étapes décrites ci-dessus.

Une fois lancé, téléchargez la clé SSH de votre instance privée, sur le bastion, en utilisant scp par exemple.

D’autre part, modifiez le security group de votre instance privée, en ouvrant le trafic entrant sur le port 22 au security group de l’instance publique. En effet sur AWS, il est possible de configurer un autre security group en source, à la place d’une IP. Cela signifie que le security group “privée” laissera passer les messages sur le port 22, en provenance des instances du security group “publique”. Cela a pour avantage de pouvoir supprimer le bastion lorsque l’on en a plus besoin, et lorsque l’on en recrée un nouveau, même si l’IP change, la connexion est toujours possible sans avoir besoin de tout reconfigurer.

Vous pouvez maintenant vous connecter à votre instance privée, en passant par le bastion. Cette technique est souvent utilisée pour se connecter aux bases de données, qui sont souvent hébergé sur des instances privées.

Ces informations sont correctes au moment de la rédaction de l’article, cependant, il est important de noter que les services AWS évoluent constamment. Il est possible que certaines fonctionnalités, noms, etc. soient différents ou aient changé depuis lors.