Wie verwende ich SSH, um auf meine EC2-Instance zuzugreifen, nachdem ich die sshd_config-Datei der Instance geändert habe?

Kurzbeschreibung

Das Ändern der Instance sshd_config Datei kann zu einem Verbindungsverweigerungsfehler führen, wenn eine Verbindung über SSH hergestellt wird.

Um zu bestätigen, dass Sie aufgrund eines Fehlers bei der Verbindungsverweigerung nicht auf die Instance zugreifen können, greifen Sie über SSH mit eingeschalteter ausführlicher Nachrichtenübermittlung auf die Instance zu. Sehen Sie sich das folgende Beispiel an:

$ ssh -i "myawskey.pem" ec2-user@ec2-11-22-33-44.eu-west-1.compute.amazonaws.com -vvv

Dieses Beispiel stellt eine Verbindung mit dem DNS-Namen her und verwendet myawskey.pem für die private Schlüsseldatei mit ec2-user als Benutzernamen. Ersetzen Sie die Schlüsseldatei und den Benutzernamen des Beispiels durch Ihre Schlüsseldatei und Ihren Benutzernamen.

Die folgende Beispielausgabe zeigt die Fehlermeldung „Verbindung verweigert“:

OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22.
ssh: connect to host ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22: Connection refused

Auflösung

**Hinweis:**Wenn Sie eine Nitro-basierte Instance verwenden, unterscheiden sich die Gerätenamen von den Beispielen in den folgenden Schritten. Anstelle von /dev/xvda oder /dev/sda1 lautet der Gerätename auf einer Nitro-basierten Instance beispielsweise /dev/nvme. Weitere Informationen finden Sie unter Gerätenamen auf Linux-Instances.

Methode 1: Verwenden Sie die serielle EC2-Konsole

Wenn Sie die serielle EC2-Konsole für Linux aktiviert haben, können Sie damit Probleme mit unterstützten Nitro-basierten Instance-Typen beheben. Die serielle Konsole hilft Ihnen bei der Behebung von Startproblemen, Netzwerkkonfigurationen und SSH-Konfigurationsproblemen. Die serielle Konsole stellt eine Verbindung zu Ihrer Instance her, ohne dass eine funktionierende Netzwerkverbindung erforderlich ist. Verwenden Sie die Amazon EC2-Konsole oder die AWS-Befehlszeilenschnittstelle (AWS CLI), um auf die serielle Konsole zuzugreifen.

Bevor Sie die serielle Konsole verwenden, gewähren Sie Zugriff auf die Konsole auf Kontoebene. Erstellen Sie anschließend AWS Identity and Access Management (IAM)-Richtlinien, die Ihren IAM-Benutzern Zugriff gewähren. Außerdem muss jede Instanz, die die serielle Konsole verwendet, mindestens einen passwortbasierten Benutzer enthalten. Wenn Ihre Instance nicht erreichbar ist und Sie den Zugriff auf die serielle Konsole nicht konfiguriert haben, folgen Sie den Anweisungen im Abschnitt Methode 2: Verwenden Sie eine Rettungs-Instance. Informationen zur Konfiguration der seriellen EC2-Konsole für Linux finden Sie unter Zugriff auf die serielle EC2-Konsole konfigurieren.

**Hinweis:**Wenn Sie beim Ausführen von AWS-CLI-Befehlen Fehler erhalten, stellen Sie sicher, dass Sie die neueste Version der AWS-CLI verwenden.

Methode 2: Verwenden Sie eine Rettungs-Instance

Warnung:

• Wenn Ihre Instance über einen Instance-Store gesichert ist oder über Instance-Speicher-Volumes verfügt, die Daten enthalten, gehen die Daten verloren, wenn Sie die Instance beenden. Weitere Informationen finden Sie unter Ermitteln des Root-Gerätetyps Ihrer Instance.
• Wenn Ihre Instance Teil einer Amazon EC2 Auto Scaling-Gruppe ist, kann das Stoppen der Instance die Instance beenden. Instances, die Sie mit Amazon EMR, AWS CloudFormation oder AWS Elastic Beanstalk starten, sind möglicherweise Teil einer AWS Auto Scaling-Gruppe. Die Beendigung der Instance in diesem Szenario hängt von den Einstellungen für den Instance Scale-In Protection für Ihre Auto Scaling-Gruppe ab. Wenn Ihre Instance Teil einer Auto Scaling-Gruppe ist, entfernen Sie die Instance vorübergehend aus der Auto Scaling-Gruppe, bevor Sie mit den Auflösungsschritten beginnen.
• Durch das Stoppen und Starten der Instance wird die öffentliche IP-Adresse Ihrer Instance geändert. Wenn Sie nicht möchten, dass sich Ihre öffentliche EC2-IP-Adresse ändert, wenn Sie Ihre Instance neu starten oder beenden, verwenden Sie eine Elastic IP-Adresse. Wenn Sie Amazon Route 53 verwenden, müssen Sie möglicherweise die Route 53-DNS-Einträge aktualisieren, wenn sich die öffentliche IP ändert.

1.    Starten Sie eine neue EC2-Instance in Ihrer Virtual Private Cloud (VPC). Verwenden Sie dasselbe Amazon Machine Image (AMI) in derselben Availability Zone wie die beeinträchtigte Instance. Die neue Instance wird zu Ihrer Rettungs-Instance.

2.    Stoppen Sie die beeinträchtigte Instance.

3.    Trennen Sie das Amazon Elastic Block Store (Amazon EBS)-Root-Volume (/dev/xvda oder /dev/sda1) von Ihrer beeinträchtigten Instance.

4.    Hängen Sie das EBS-Volume als sekundäres Gerät** (/dev/sdf**) an die Rettungs-Instance an.

5.    Verwenden Sie SSH, umeine Verbindung zu Ihrer Rescue-Instance herzustellen.

6.    Führen Sie den Befehl lsblk aus, um Geräte anzuzeigen:

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
 └─xvdf1 202:81   0   8G  0 part

7.    Erstellen Sie ein Mount-Point-Verzeichnis (/rescue) für das neue Volume, das Sie in Schritt 4 an die Rettungs-Instance angehängt haben:

$ sudo mkdir /mnt/rescue

8.    Mounten Sie das Volume in dem Verzeichnis, das Sie in Schritt 7 erstellt haben:

$ sudo mount -t xfs -o nouuid /dev/xvdf1 /mnt/rescue/

Führen Sie den folgenden Befehl aus, um ext3- und ext4-Dateisysteme zu mounten:

$ sudo mount /dev/xvdf1 /mnt/rescue

**Hinweis:**Die Syntax des vorherigen Mount-Befehls kann variieren. Für weitere Informationen führen Sie den Befehl man mount aus.

9.    Führen Sie den Befehl lsblk erneut aus, um zu überprüfen, ob das Volume das Verzeichnis gemountet hat:

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
└─xvdf1 202:81   0   8G  0 part /mnt/rescue

Korrigieren oder kopieren Sie die Datei sshd_config

Sie können die Datei sshd_config auf Ihrer beeinträchtigten Instance untersuchen und bei Bedarf Ihre Änderungen rückgängig machen. Verwenden Sie die ausführliche SSH-Nachrichtenausgabe, um Sie zum Fehlerort in der Datei zu führen:

$ sudo vi /mnt/rescue/etc/ssh/sshd_config

Oder führen Sie den folgenden Befehl aus, um die Datei sshd_config von der Rettungs-Instance in Ihre beeinträchtigte Instance zu kopieren. Dieser Befehl ersetzt den Inhalt der Datei sshd\ _config auf Ihrer ursprünglichen Instance:

$ sudo cp /etc/ssh/sshd_config /mnt/rescue/etc/ssh/sshd_config

Schließen Sie das Volume erneut an die ursprüngliche Instance an und testen Sie die Verbindung

Hinweis:Wenn Sie Methode 2 verwendet haben: Verwenden Sie eine Rettungs-Instance und führen Sie dann die folgenden Schritte aus.

1.    Führen Sie den Befehl umount aus, um das Volume auszuhängen:

$ sudo umount /mnt/rescue/

2.    Trennen Sie das sekundäre Volume von der Rettungs-Instance und hängen Sie das Volume dann als /dev/xvda (Root-Volume) an die ursprüngliche Instance an.

3.    Starten Sie die Instance.

4.    Stellen Sie mithilfe von SSH eine Verbindung zur Instance her, um zu überprüfen, ob Sie die Instance erreichen können.

Weitere Informationen

Warum kann ich mit SSH keine Verbindung zu meiner Amazon EC2 Linux-Instance herstellen?