Wie kann ich den Zugriff auf die serielle EC2-Konsole einer nicht erreichbaren oder unzugänglichen Linux-Instance konfigurieren?

Letzte Aktualisierung: 22.03.2022

Meine Linux-Instance in der Amazon Elastic Compute Cloud (Amazon EC2) ist nicht erreichbar oder nicht zugänglich. Ich habe den Zugriff auf die serielle EC2-Konsole nicht auf Betriebssystemebene konfiguriert. Wie kann ich die Betriebssystemkonfigurationen für die serielle EC2-Konsole ändern und das Passwort für jeden Betriebssystembenutzer für den Zugriff auf die Instance festlegen?

Kurzbeschreibung

Gehen Sie wie folgt vor, um den Zugriff auf die serielle Konsole zu konfigurieren:

1.    Greifen Sie auf das Root-Volume der Instance zu.

2.    Legen Sie das Passwort für den Root-Benutzer oder einen anderen Betriebssystembenutzer fest.

3.    Prüfen und aktualisieren Sie die GRUB-Einstellungen für die serielle Konsole.

Hinweis: Sie können Schritt 3 überspringen, wenn die serielle EC2-Konsole auf der betroffenen Instance ordnungsgemäß funktioniert und Sie nur das Passwort für Ihren Betriebssystembenutzer festlegen müssen.

Voraussetzungen

Zum Verwenden der seriellen Konsole müssen Sie die Voraussetzungen erfüllen, außer zum Festlegen eines Betriebssystembenutzerpassworts. Das Festlegen eines Passworts wird in der folgenden Auflösung erläutert.

Auflösung

Mit einer Rescue-Instance auf das Root-Volume der Instance zugreifen

Erstellen Sie eine temporäre Rescue-Instance und stellen Sie dann Ihr Volume aus dem Amazon Elastic Block Store (Amazon EBS) erneut auf der Rescue-Instance bereit. In der Rescue-Instance können Sie die GRUB-Einstellungen für die serielle Konsole überprüfen und ändern. Sie können auch das Passwort für den Root-Benutzer oder einen anderen Betriebssystembenutzer festlegen.

Wichtig: Führen Sie dieses Verfahren nicht für eine über den Instance-Speicher gesicherte Instance aus. Da das Wiederherstellungsverfahren einen Stopp und Start Ihrer Instance erfordert, gehen alle Daten auf dieser Instance verloren. Weitere Informationen finden Sie unter Bestimmen des Root-Gerätetyps Ihrer Instance.

1.    Erstellen Sie einen EBS-Snapshot des Root-Volumes. Weitere Informationen finden Sie unter Erstellen von Amazon EBS-Snapshots.

2.    Öffnen Sie die Amazon EC2-Konsole.

Hinweis: Stellen Sie sicher, dass Sie sich in der richtigen Region befinden.

3.    Wählen Sie im Navigationsbereich Instances und dann die beeinträchtigte Instance aus.

4.    Wählen Sie Instance-Status,Instance stoppen und dann Stopp aus.

5.    Wählen Sie auf der Registerkarte Speicher unter Geräte blockieren die Volume-ID für /dev/sda1 oder /dev/xvda aus.

Hinweis: Das Root-Gerät ist je nach AMI unterschiedlich, aber /dev/xvda oder /dev/sda1 sind für das Root-Gerät reserviert. Amazon Linux 1 und 2 verwenden beispielsweise /dev/xvda. Andere Distributionen wie Ubuntu 16, 18, CentOS 7 und RHEL 7.5 verwenden /dev/sda1.

6.    Wählen Sie Aktionen, Volume trennen und dann Ja, trennen. Beachten Sie die Availability Zone.

Hinweis: Sie können das EBS-Volume markieren, bevor Sie es trennen, um es in späteren Schritten besser identifizieren zu können.

7.    Starten Sie eine EC2-Rescue-Instance in derselben Availability Zone.

Hinweis: Je nach Produktcode müssen Sie möglicherweise eine EC2-Instance desselben Betriebssystemtyps starten. Wenn es sich bei der beeinträchtigten EC2-Instance beispielsweise um ein kostenpflichtiges RHEL-AMI handelt, müssen Sie ein AMI mit demselben Produktcode starten. Weitere Informationen finden Sie unter Abrufen des Produktcodes für Ihre Instance.

Wenn auf der ursprünglichen Instance SELinux ausgeführt wird (RHEL, CentOS 7 oder 8 zum Beispiel), starten Sie die Rescue-Instance über ein AMI, das SELinux verwendet. Wenn Sie ein AMI auswählen, auf dem ein anderes Betriebssystem ausgeführt wird, wie Amazon Linux 2, hat jede geänderte Datei auf der ursprünglichen Instance beschädigte SELinux-Labels.

8.    Nachdem die Rescue-Instance gestartet wurde, wählen Sie im Navigationsbereich Volumes und dann das getrennte Root-Volume der beeinträchtigten Instance aus.

9.    Wählen Sie Aktionen, Volume anfügen.

10.    Wählen Sie die ID der Rescue-Instance (id-xxxxx) und legen Sie dann ein nicht verwendetes Gerät fest. In diesem Beispiel /dev/sdf.

11.     Stellen Sie mit SSH eine Verbindung zur Rescue-Instance her.

12.    Führen Sie den Befehl lsblk aus, um Ihre verfügbaren Festplattengeräte anzuzeigen:

lsblk

Im Folgenden finden Sie ein Beispiel für die Ausgabe:

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0     0   15G  0 disk
└─xvda1 202:1     0   15G  0 part /
xvdf    202:0     0   15G  0 disk
    └─xvdf1 202:1 0   15G  0 part

Hinweis: Nitro-basierte Instances stellen EBS-Volumes als NVMe-Blockgeräte dar. Die vom Befehl lsblk in Nitro-basierten Instances generierte Ausgabe zeigt die Festplattennamen als nvme[0-26]n1. Weitere Informationen finden Sie unter Amazon EBS und NVMe auf Linux-Instances. Im Folgenden finden Sie ein Beispiel für die Befehlsausgabe von lsblk auf einer Nitro-basierten Instance:

NAME           MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
nvme0n1        259:0    0    8G  0 disk 
└─nvme0n1p1    259:1    0    8G  0 part /
└─nvme0n1p128  259:2    0    1M  0 part 
nvme1n1        259:3    0  100G  0 disk 
└─nvme1n1p1    259:4    0  100G  0 part /

13.    Führen Sie den folgenden Befehl aus, um Root zu werden:

sudo -i

14.    Hängen Sie die Root-Partition des eingehängten Volumes in /mnt ein. Im vorherigen Beispiel ist /dev/xvdf1 oder /dev/nvme2n1p2 die Root-Partition des eingehängten Volumes. Weitere Informationen finden Sie unter Verfügbarmachen eines Amazon EBS-Volumes für die Verwendung unter Linux.

Hinweis: Ersetzen Sie im folgenden Beispiel /dev/xvdf1 durch die richtige Root-Partition für Ihr Volume.

mount -o nouuid /dev/xvdf1 /mnt

Hinweis: Falls /mnt in Ihrer Konfiguration nicht vorhanden ist, erstellen Sie ein Mount-Verzeichnis und hängen Sie dann die Root-Partition des eingehängten Volumes in diesem neuen Verzeichnis ein.

mkdir /mnt
mount -o nouuid /dev/xvdf1 /mnt

Sie können jetzt über das Mount-Verzeichnis auf die Daten der beeinträchtigten Instance zugreifen.

15.    Hängen Sie /dev, /run, /proc und /sys der Rescue-Instance auf denselben Pfaden wie das neu eingehängte Volume ein:

for m in dev proc run sys; do mount -o bind {,/mnt}/$m; done

Rufen Sie die Funktion chroot auf, um in das Mount-Verzeichnis zu wechseln.

Hinweis: Wenn Sie separate /boot- und /etc-Partitionen haben, hängen Sie sie in /mnt/boot und /mnt/etc ein, bevor Sie den folgenden Befehl ausführen.

chroot /mnt

Legen Sie das Passwort für den Root-Benutzer oder einen anderen Betriebssystembenutzer fest.

Legen Sie mit dem Befehl passwd das Passwort für Ihren Betriebssystembenutzer fest. Im folgenden Beispiel ist der Benutzer Root:

passwd root

Prüfen und aktualisieren Sie die GRUB-Einstellungen für die serielle Konsole.

Hinweis: Sie können diesen Schritt überspringen, wenn die serielle EC2-Konsole auf der betroffenen Instance ordnungsgemäß funktioniert und Sie nur das Passwort für Ihren Betriebssystembenutzer festlegen müssen.

Der unterstützte serielle Konsolenport für Linux ist ttyS0. Wenn der Bildschirm beim Anschließen an die serielle EC2-Konsole schwarz bleibt und nichts ausgibt, sollten Sie sicherstellen, dass der Konsoleneintrag in den GRUB-Einstellungen richtig konfiguriert ist. Die unten aufgeführten Beispiele stammen aus den AWS Marketplace-AMIs für die verschiedenen Distributionen, in denen die serielle Konsole ordnungsgemäß funktioniert:

GRUB2 für Amazon Linux 2, RHEL und CentOS 7

1.    Stellen Sie sicher, dass der Konsoleneintrag für ttyS0 in der Zeile GRUB_CMDLINE_LINUX_DEFAULT der Datei /etc/default/grub richtig gesetzt ist:

Amazon Linux 2

GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"

RHEL 7

GRUB_CMDLINE_LINUX="console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto"

CentOS 7

GRUB_CMDLINE_LINUX="console=tty0 crashkernel=auto net.ifnames=0 console=ttyS0"

2.    Wenn der Konsoleneintrag für ttyS0 nicht gesetzt ist, fügen Sie ihn in der Zeile GRUB_CMDLINE_LINUX_DEFAULT hinzu. Aktualisieren Sie dann GRUB, um die Datei /boot/grub2/grub.cfg neu zu generieren:

grub2-mkconfig -o /boot/grub2/grub.cfg

GRUB1 (Legacy-GRUB) für Red Hat 6 und Amazon Linux 1

1.    Stellen Sie sicher, dass der Konsoleneintrag für ttyS0 in der Kernelzeile der Datei /boot/grub/grub.conf richtig gesetzt ist:

Amazon Linux 1

kernel /boot/vmlinuz-4.14.252-131.483.amzn1.x86_64 root=LABEL=/ console=tty1 console=ttyS0 selinux=0 nvme_core.io_timeout=4294967295

Red Hat 6

kernel /boot/vmlinuz-2.6.32-573.el6.x86_64 console=ttyS0 console=ttyS0,115200n8 ro root=UUID=0e6b1614-7bbe-4d6e-bc78-a5556a123ba8 rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 xen_blkfront.sda_is_xvda=1 console=tty0 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_LVM rd_NO_DM

2.    Wenn der Konsoleneintrag für ttyS0 nicht gesetzt ist, fügen Sie ihn gemäß den vorhergehenden Beispielen in die Datei /boot/grub/grub.conf ein.

GRUB2 für Ubuntu 16.04, 18.04 und 20.04

1.    Stellen Sie sicher, dass der Konsoleneintrag für ttyS0 in der Zeile GRUB_CMDLINE_LINUX_DEFAULT der Datei /etc/default/grub.d/50-cloudimg-settings.cfg richtig gesetzt ist:

GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295"

2.    Wenn der Konsoleneintrag console=ttyS0 nicht vorhanden ist, fügen Sie ihn in der Zeile GRUB_CMDLINE_LINUX_DEFAULT hinzu. Aktualisieren Sie anschließend die GRUB-Konfiguration mit dem folgenden Befehl:

update-grub

GRUB2 für RHEL 8 und CentOS 8

1.    Führen Sie den Befehl grubby --default-kernel aus, um den aktuellen Standardkernel zu sehen:

grubby --default-kernel

2.    Führen Sie den Befehl grubby --info=ALL aus, um alle verfügbaren Kernels, ihre Indizes und ihre Argumente zu sehen:

grubby --info=ALL

3.    Stellen Sie sicher, dass der Konsoleneintrag für ttyS0 in der Zeile args für den in Schritt 1 beschriebenen Standardkernel richtig gesetzt ist.

RHEL 8

index=0
kernel="/boot/vmlinuz-4.18.0-305.el8.x86_64"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params"
root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
initrd="/boot/initramfs-4.18.0-305.el8.x86_64.img $tuned_initrd"
title="Red Hat Enterprise Linux (4.18.0-305.el8.x86_64) 8.4 (Ootpa)"
id="0c75beb2b6ca4d78b335e92f0002b619-4.18.0-305.el8.x86_64"

CentOS 8

index=2
kernel="/boot/vmlinuz-4.18.0-193.19.1.el8_2.x86_64"
args="ro console=ttyS0,115200n8 no_timer_check net.ifnames=0 nvme_core.io_timeout=4294967295 nvme_core.max_retries=10 crashkernel=auto $tuned_params"
root="UUID=b437cbaa-8fe5-49e4-8537-0895c219037a"
initrd="/boot/initramfs-4.18.0-193.19.1.el8_2.x86_64.img $tuned_initrd"
title="CentOS Linux (4.18.0-193.19.1.el8_2.x86_64) 8 (Core)"
id="dc49529e359897df0b9664481b009b1f-4.18.0-193.19.1.el8_2.x86_64"

4.    Wenn der Konsoleneintrag für ttyS0 nicht gesetzt ist, hängen Sie ihn mit dem folgenden grubby-Befehl an die args des Standardkernels an:

grubby --args console=ttyS0,115200n8 --update-kernel DEFAULT

Hängen Sie das Root-Volume aus und trennen Sie es von der Rescue-Instance und fügen Sie das Volume dann an die beeinträchtigte Instance an

1.    Beenden Sie chroot und hängen Sie /dev, /run, /proc und /sys aus:

exit
umount /mnt/{dev,proc,run,sys,}

2.    Wählen Sie in der Amazon EC2-Konsole Instances und dann die Rescue-Instance aus.

3.    Wählen Sie Instance-Status,Instance stoppen und dann Ja, Stopp aus.

4.    Trennen Sie das Root-Volume id-xxxxx (das Volume der beeinträchtigten Instance) von der Rescue-Instance.

5.    Hängen Sie das Root-Volume, das Sie in Schritt 4 getrennt haben, als Root-Volume (/dev/sda1) an die beeinträchtigte Instance an, und starten Sie dann die Instance.

Hinweis: Das Root-Gerät ist je nach AMI unterschiedlich. Die Namen /dev/xvda oder /dev/sda1 sind für das Root-Gerät reserviert. Amazon Linux 1 und 2 verwenden beispielsweise /dev/xvda. Andere Distributionen wie Ubuntu 16, 18, CentOS 7 und RHEL 7.5 verwenden /dev/sda1.

Jetzt können Sie über die serielle EC2-Konsole mit dem im vorherigen Schritt für den Root-Benutzer oder einen anderen Betriebssystembenutzer definierten Passwort auf das Betriebssystem der beeinträchtigten Instance zugreifen.


War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?