Découvrez les différentes façons de vous connecter à une instance EC2 sur AWS dans notre toute nouvelle mini-série d’articles !

Au cours des prochains articles, nous partagerons avec vous les différentes techniques pour accéder à vos instances EC2 en vous fournissant des instructions claires et les bonnes pratiques liées à chaque méthodes.

Dans cet article nous verrons la méthode classique: l’utilisation de clés SSH.

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

Je porte votre attention sur le fait que se sera votre seule et unique chance que configurer une paire de clés SSH via la console de management AWS. Cela sous-entend que si vous oubliez ou que vous vous trompez, il faudra utiliser une autre méthode pour vous connecter à votre instance ou détruire l’instance et la recréer… Mais pas de panique, si aucune clé n’est renseignée au moment de créer l’instance, par sécurité un pop-up vous demandera d’en sélectionner une ou de volontairement choisir l’option de ne pas en utiliser.

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>” <user>@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.