Utiliser la console série EC2 quand SSH est mort

La console série EC2, c’est le chariot d’urgence d’AWS : un terminal texte attaché au port série de l’instance qui fonctionne même quand la configuration réseau, le pare-feu ou le sshd de l’instance est complètement brisé. Elle exige trois choses à mettre en place avant l’urgence : l’accès à la console série activé au niveau du compte, une permission IAM, et un utilisateur du système avec un mot de passe — parce que la console série vous dépose sur une invite de connexion, et la plupart des images infonuagiques arrivent avec la connexion par mot de passe désactivée. Préparez ça un après-midi tranquille et une instance verrouillée devient un correctif de cinq minutes au lieu d’une chirurgie d’échange de volume.

Ce qui se passe

SSH dépend de toute la pile : chemin réseau, groupes de sécurité, configuration réseau du système, un sshd en marche et des clés valides. La console série contourne tout ça. Elle se connecte à ttyS0 — le port série virtuel — par le plan de contrôle d’AWS, comme le ferait un câble console physique sur un serveur en baie. Les groupes de sécurité, les tables de routage et les règles iptables de l’instance ne la concernent pas, et c’est exactement pourquoi c’est le bon outil quand vous vous êtes enfermé dehors avec un pare-feu, brisé /etc/fstab, massacré la configuration netplan ou NetworkManager, ou tué sshd avec une mauvaise modification de configuration.

Les contraintes : elle est disponible sur les instances Nitro seulement (virtualisées — le bare metal est exclu), l’accès doit être activé par compte et par région, une session par instance à la fois, et le côté système présente une invite login: standard sur la ligne série. Ce dernier point est le piège. Les images Ubuntu, Amazon Linux et Debian arrivent sans mot de passe sur aucun utilisateur, alors la console série vous montre une invite de connexion que vous ne pouvez pas franchir. Il faut avoir défini un mot de passe d’avance — ou en définir un maintenant par un autre canal (SSM, bidouille de user data, ou échange de volume) — d’où le conseil honnête : préparez ça avant d’en avoir besoin. Il n’y a aucuns frais supplémentaires pour utiliser la console série.

Quoi vérifier en premier

L’instance est-elle basée sur Nitro? aws ec2 describe-instance-types --instance-types m7i.large --query 'InstanceTypes[].Hypervisor' retourne nitro pour les familles prises en charge. Les vieux types Xen n’ont pas de console série.
L’accès à la console série est-il activé pour le compte dans cette région? Il est désactivé par défaut.
Avez-vous la permission IAM? ec2-instance-connect:SendSerialConsoleSSHPublicKey contrôle l’accès, navigateur comme CLI.
Un utilisateur du système a-t-il un mot de passe? Pas de mot de passe, pas de connexion — la console va se connecter et vous laisser quand même devant une invite infranchissable.
L’instance roule-t-elle? La console série s’attache aux instances en marche (et en redémarrage); une instance arrêtée n’a pas de console à attacher.

Comment vérifier

Vérifiez et activez l’accès au niveau du compte :

aws ec2 get-serial-console-access-status

# L'activer (à l'échelle du compte, par région)
aws ec2 enable-serial-console-access

Dans la console, la même bascule vit sous EC2 > Paramètres (Attributs du compte) > EC2 Serial Console. Pour ouvrir une session depuis le navigateur : EC2 > Instances > sélectionner l’instance > Actions > Surveiller et dépanner > Console série EC2. Depuis un terminal, vous poussez une clé publique SSH temporaire et vous vous connectez au point de terminaison régional de la console série :

aws ec2-instance-connect send-serial-console-ssh-public-key \
  --instance-id i-0123456789abcdef0 \
  --serial-port 0 \
  --ssh-public-key file://~/.ssh/id_ed25519.pub

ssh -i ~/.ssh/id_ed25519 \
  i-0123456789abcdef0.port0@serial-console.ec2-instance-connect.ca-central-1.aws

La clé est valide 60 secondes, alors connectez-vous rapidement. Les préalables complets et les points de terminaison par région sont dans la documentation EC2 à https://docs.aws.amazon.com/ec2/.

La procédure

Activez l’accès et définissez un mot de passe de secours maintenant, pas pendant l’incident. Activez l’accès à la console série dans chaque région de production, accordez la permission IAM au rôle d’opérations, et définissez un mot de passe fort sur un utilisateur local dédié (sudo passwd ec2-user, ou un utilisateur console-rescue créé exprès) dans vos images de base. Rangez le mot de passe dans votre gestionnaire de secrets.
Ouvrez la session et connectez-vous. Méthode navigateur ou SSH ci-dessus. Si l’écran est vide, appuyez sur Entrée pour réveiller le getty. Vous atterrissez dans un shell normal avec root disponible via sudo.
Réparez ce qui vous a enfermé dehors. Les suspects habituels, en ordre observé : une règle iptables/ufw/firewalld qui bloque le port 22 (sudo ufw status, sudo iptables -L -n), une configuration sshd brisée (sudo sshd -t nomme la ligne fautive, puis sudo systemctl restart sshd), une mauvaise entrée /etc/fstab qui tient le démarrage en otage (commentez-la, redémarrez), ou une modification réseau qui a couché eth0 (ip a, puis réparez le fichier netplan/NetworkManager et réappliquez).
Regardez un démarrage brisé en direct. Redémarrez depuis la session et la console série montre GRUB et la sortie du noyau en temps réel — l’unité défaillante ou le message de panique défile devant vous au lieu d’être une chose à déduire d’une capture d’écran. Sur les distributions où vous ne voyez rien, la ligne de commande du noyau manque peut-être de console=ttyS0; Amazon Linux arrive correctement configuré.
Vérifiez que SSH fonctionne à nouveau avant de fermer la console. Testez le vrai chemin de connexion depuis votre poste. La session série est votre corde de sécurité — ne la lâchez pas avant que la porte normale soit confirmée ouverte. Si SSH expire encore de l’extérieur, le problème restant est sur le chemin réseau AWS, et la liste de vérification des délais SSH couvre ce côté.

Quand c’est la mauvaise approche

Si l’agent SSM est sur l’instance, en santé et enregistré, Session Manager est la meilleure porte au quotidien — authentifiée par IAM, journalisée, sans mot de passe; gardez la console série pour quand l’agent ou le réseau sous lui est la victime. Si l’instance ne démarre pas du tout parce que le système de fichiers racine est corrompu, la console série vous montre l’échec mais ne peut pas toujours le réparer — ça escalade vers le flot arrêter, détacher, réparer-sur-une-aide, rattacher décrit dans la procédure de récupération des vérifications de statut. Et sur les instances de génération Xen, il n’y a pas de console série; l’échange de volume est la seule chirurgie disponible.

Erreurs courantes

Découvrir pendant la panne que l’accès à la console série n’a jamais été activé et qu’aucun utilisateur n’a de mot de passe — l’outil fonctionne, mais seulement pour ceux qui se sont préparés.
Quitter la session série avant de confirmer que SSH fonctionne, puis payer pour un deuxième verrouillage.
Choisir un mot de passe de secours faible parce que « c’est juste la console série » — c’est une porte avec accès root; traitez le mot de passe en conséquence.
Supposer que la console série a besoin d’un réseau d’instance en santé — non; c’est justement tout l’intérêt.

Prévention

Activez l’accès à la console série dans chaque région de production comme partie de la base du compte, et auditez la permission IAM vers un petit groupe d’opérations.
Intégrez un utilisateur de secours avec mot de passe dans vos AMI, le mot de passe rangé au coffre et pivoté.
Préférez Session Manager pour l’accès quotidien pour que le port 22 puisse rester complètement fermé.
Testez le chemin complet chaque trimestre : ouvrir une session, se connecter, sortir. Une procédure de secours non testée est un espoir, pas une procédure.
Gardez console=ttyS0 sur la ligne de commande du noyau des images maison pour que la sortie de démarrage soit réellement visible.

Une console hors bande transforme « on est enfermés hors de la production » d’incident en corvée — mais seulement si le compte a été préparé avant le jour où ça compte. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.