Erfahren Sie, wie Sie Probleme im Zusammenhang mit Sicherheitsgruppen, Schlüsselpaaren, Netzwerkkonfigurationen usw. beheben, um einen reibungslosen Zugriff auf Ihre Amazon EC2-Instanzen zu gewährleisten.
Updated by Emma on 2024/12/30
Einige neu bei AWS registrierte Benutzer können Probleme haben beim Herstellen einer SSH-Verbindung mit einer Linux-EC2-Instanz. Machen Sie sich keine Sorgen, dieser Artikel hilft Ihnen dabei, häufige Ursachen zu beheben!
Häufige Gründe für das Nicht-Erreichen einer Verbindung zu EC2 über SSH fallen grundsätzlich in zwei Kategorien: Verbindungszeitüberschreitung und Berechtigungsfehler.
Verbindungstimeout: Fehlermeldungen enthalten normalerweise Schlüsselwörter wie „connect“, zum Beispiel „Connection Timed Out“. Dies liegt in der Regel an fehlerhaften Netzwerkeinstellungen, wobei IP, Sicherheitsgruppe, ACL, Subnetzroutentabelle und die Netzwerkkonfiguration des Benutzers überprüft werden müssen.
Berechtigungsfehler: Fehlermeldungen enthalten in der Regel Schlüsselwörter wie „Berechtigung“ oder „Schlüssel“, zum Beispiel „Zugriff verweigert“ oder Warnungen darüber, dass Schlüssel nicht registriert oder nicht vorhanden sind. Dies liegt in der Regel an einer fehlerhaften Verwendung von Schlüsseln oder Benutzernamen.
Problembeschreibung
Sie haben eine Amazon EC2 Linux-Instanz erstellt und gestartet, können sich aber nicht mit SSH oder Tools wie PuTTY auf die Instanz verbinden. Beim Herstellen der Verbindung zur Instanz treten Ihnen ein Timeout-Fehler auf, wie „Netzwerkfehler: Verbindungstimeout“ oder „Fehler beim Herstellen der Verbindung zu [Instanz], Grund: -> Verbindungstimeout: connect“. Dieses Problem wird in der Regel durch fehlerhafte Einstellungen von Netzwerkkomponenten wie Sicherheitsgruppen, Routentabellen und Netzwerk-ACLs verursacht. Bitte befolgen Sie die unten stehenden Schritte zur Problembehebung, um die Netzwerkangebung zu überprüfen.
1. Überprüfen Sie Sicherheitsgruppen
Im Sicherheitsgruppen des EC2-Instanz sicherstellen dass eingehender Datenverkehr für das SSH-Protokoll (Standardport 22) erlaubt ist.
Bei einem Office-LAN kann Ihre IP-Adresse nicht fest sein und sich bei jedem Verbindungsaufbau ändern. In diesem Fall wird empfohlen, die Quelle auf den IP-Bereich Ihres Büronetzes zu setzen anstatt auf eine einzelne IP.
Hinweis: Standardmäßig kann die Instanz ebenfalls nicht gepinged werden. Wenn Sie diese Instanz pingen möchten, müssen Sie eine Regel hinzufügen, die das ICMP-Protokoll zulässt, auf ähnliche Weise.
Öffnen Sie die Amazon EC2-Konsole.
Im Navigationsbereich wählen Sie Instances aus.
Finden Sie die EC2-Instanz, zu der Sie über SSH eine Verbindung herstellen möchten.
Im Reiter Description am unteren Bildschirmrand wählen Sie die Sicherheitsgruppe der EC2-Instanz aus, zu der Sie eine Verbindung herstellen möchten.
In der Registerkarte Inbound im Bereich am unteren Bildschirmrand stellen Sie sicher, dass eine Regel festgelegt ist, um den SSH-Zugriff von Ihrer aktuellen öffentlichen IP-Adresse zuzulassen. Wenn die von Ihrem Gerät verwendete IP-Adresse nicht in der Liste steht, wählen Sie Edit und dann Add rule.
Für Source wählen Sie Ihre aktuelle IP-Adresse. „0.0.0.0/0“ bedeutet dass es für alle IPs offen ist.
Wählen Sie Save.
2. Überprüfen Sie, ob das Subnetz ein öffentliches Subnetz ist
Eine öffentliche Subnetz ist ein Subnetz, das den Internetzugriff ermöglicht. Wenn Ihr EC2 in einem privaten Subnetz liegt, kann das externe Internet nicht aktiv verbinden und SSH wird fehlschlagen.
Öffnen Sie die Amazon VPC-Konsole.
Im Navigationsbereich wählen Sie Route Tables aus und dann Ihre VPC-Route-Tabelle aus der Liste.
In der Registerkarte Routes sicherstellen dass eine Standardroute auf das Internetgateway zeigt.
Falls nicht, wählen Sie Internet Gateways aus dem Navigationsbereich und kopieren Sie Ihre Internet-Gateway-ID. Wenn kein Internetgateway vorhanden ist, erstellen Sie eines und fügen Sie es Ihrem VPC hinzu. Stellen Sie sicher, die neue Internet-Gateway-ID zu kopieren.
Bearbeiten und erstellen Sie eine Route, die „0.0.0.0/0“ an Ihre Internet-Gateway-ID weiterleitet.
Speichern Sie die Routentabelle.
3. Überprüfen Sie die Netzwerkzugriffssteuerungsliste (ACL) des Subnetzes
Die ACL ist ein Firewall auf Ebene des Subnetzes. Die Standard-Netzwerkacl erlaubt allen eingehenden und ausgehenden Datenverkehr. Wenn Sie keine Änderungen an der ACL vorgenommen haben, überspringen Sie diesen Schritt.
Öffnen Sie die Amazon VPC-Konsole.
Im Navigationsbereich wählen Sie Subnets aus und dann Ihr Subnetz.
Im Reiter Description finden Sie Network ACL und wählen Sie dann deren ID (acl-xxxxxxxx) aus.
Wählen Sie die Netzwerks-ACL aus. Für Inbound Rules überprüfen Sie ob die Regeln den Datenverkehr von Ihrem Computer zulassen. Wenn nicht löschen oder ändern Sie die Regeln die den Datenverkehr von Ihrem Computer blockieren. Für Outbound Rules überprüfen Sie ob die Regeln den Datenverkehr zu Ihrem Computer zulassen. Wenn nicht löschen oder ändern Sie die Regeln die den Datenverkehr zu Ihrem Computer blockieren.
4. Bestätigen Sie ob die IP-Adresse geändert wurde
Im Navigationsbereich Instanzen auswählen.
Finden Sie die EC2-Instanz, zu der Sie eine SSH-Verbindung herstellen möchten.
Im Description-Tab am unteren Bildschirmrand überprüfen Sie ob die Public IP mit der von Ihnen verwendeten IP-Adresse übereinstimmt. Falls sich die IP-Adresse geändert hat, verwenden Sie die neue IP-Adresse.
5. Überprüfen Sie das AMI
Bitte überprüfen Sie, ob Sie derzeit ein AMI im Quick Start oder im Marketplace verwenden. Wenn Sie sich nicht sicher sind, dass ein bestimmtes AMI sicher ist, vermeiden Sie es, Community-Images zu verwenden. Community-Images werden von Einzelpersonen veröffentlicht und AWS kann diese nicht überwachen. Einige Community-Images können spezielle Sicherheitsverwaltungen und -kontrollen haben, die eine direkte SSH-Zugriff verhindern. In diesem Fall stoppen Sie den aktuellen Server und starten Sie einen neuen mit einem offiziellen oder Marketplace-Image.
6. Überprüfe die Instanzbelastung
Der Server könnte überlastet sein, was dazu führt dass der sshd-Dienst fehlerhaft funktioniert und keine neuen SSH-Anfragen akzeptiert. Dies kann durch die Beobachtung von CloudWatch-Metriken bestätigt werden. Der einfachste Weg in diesem Fall ist es den Instanz neu zu starten um zu sehen ob das Problem behoben ist. Wenn nicht kann das System Manager Sitzungsverwaltungstool verwendet werden um eine Sitzung zu öffnen und Befehle auszuführen um unnötige Ressourcen zu beenden.
7. Andere Gründe
Wenn alle oben genannten Schritte überprüft wurden und kein Problem vorliegt, prüfen Sie die folgenden Gründe:
Port 22 ist blockiert: Wenn Sie sich im Büro oder in einem Hotel-WLAN-Bereich befinden, versuchen Sie ein anderes Netzwerk, um zu überprüfen, ob das öffentliche Netzwerk Port 22 blockiert.
Überprüfen Sie, ob die Firewall Ihres Computers den Port 22 blockiert.
Problembeschreibung
Sie haben eine EC2 erstellt und gestartet, können aber nicht über SSH auf die Instanz zugreifen, mit Fehlermeldungen wie "Host key not found in [Verzeichnis]", "Permission denied (publickey)" oder "Authentication failed, permission denied". Dieses Problem wird normalerweise durch falsche Schlüssel oder Benutzernamen verursacht. Im Folgenden finden Sie spezifische Schritte zur Fehlerbehebung.
1. Überprüfen Sie ob das Schlüsselpaar korrekt ist
Jede EC2-Instanz hat einen Schlüssel beim Start. Dieser Schlüssel ist die einzige Möglichkeit sich das erste Mal bei der EC2 anzumelden und kann nur vor dem Start der Instanz heruntergeladen werden. Zuerst wählen Sie Ihre Instanz aus und überprüfen Sie den Namen des Schlüsselpaares auf der Description Seite, um sicherzustellen, dass Sie den richtigen Schlüssel verwenden.
Wenn dieses Element leer ist, können Sie nicht per SSH in die Instanz einloggen. Bitte stoppen Sie die Instanz, starten Sie eine neue Instanz und vergessen Sie nicht, den Schlüssel herunterzuladen.
2. Falscher Benutzername
Wenn Sie ein offizielles Image verwenden, lautet der korrekte Benutzername wie folgt:
AMI | Benutzername |
Amazon Linux 2 oder Amazon Linux AMI | ec2-user |
CentOS AMI | CentOS |
Debian AMI | Administrator oder root |
Fedora AMI | ec2-user oder fedora |
RHEL AMI | ec2-user oder root |
SUSE AMI | ec2-user oder root |
Ubuntu AMI | Ubuntu |
Wenn es sich um eine Community-Version des AMI handelt, kann der Benutzername nicht garantiert werden. Bitte kontaktieren Sie den Ersteller des AMI oder wechseln Sie zu einem offiziellen AMI.
3. Überprüfen Sie Ihr Schlüsselformat
Generell befindet sich der für SSH benötigte Schlüssel im „pem“-Format. Wenn Sie einen Windows-Rechner verwenden und mit PuTTY anmelden, müssen Sie das Format von „pem“ in „ppk“ konvertieren.
4. Überprüfe Schlüsselberechtigungen
Wenn Sie den Fehler „bad permissions: ignore key: my_private_key.pem Permission denied (publickey)“ erhalten.
Diese Situation entsteht, weil die Berechtigungen Ihrer privaten Schlüsseldatei zu hoch sind und jedem Benutzer das Lesen und Schreiben ermöglichen. Um Ihre private Schlüsseldatei zu schützen, ignoriert SSH Ihren Schlüssel. Die Lösung besteht darin, die Berechtigungen des Schlüssels mit dem Befehl zu ändern:
chmod 400 my_private_key.pem
5. known_host bezogene Fehler
Diese Situation tritt normalerweise auf beim Wechsel von EIPs, zum Beispiel wurde eine EIP mit Schlüssel A an Maschine A angehängt. Wenn die EIP auf Maschine B mit Schlüssel B umgeschaltet wird, stimmt der known_host-Eintrag für diese IP nicht überein.
Die Lösung besteht darin die known_hosts-Datei (Linux/Mac Pfad: ~/.ssh/known_hosts) zu öffnen und den entsprechenden Eintrag für diese IP-Adresse zu löschen.
Vinchin Backup & Recovery unterstützt AWS EC2-Backups, ermöglicht es Benutzern, Instanzen mit ihrer AWS-Zugriffsschlüssel-ID hinzuzufügen und vollständige, inkrementelle oder differentielle Backups zu konfigurieren. Es bietet flexible Wiederherstellungsoptionen, einschließlich ganzer Instanzen, einzelner Volumes und spezifischer Dateien, mit direkter Wiederherstellung auf andere Virtualisierungsplattformen. Durch die Integration mit Amazon S3 für sicheres Archivierung ermöglicht es auch V2V-Migrationen zu Plattformen wie VMware, Hyper-V und Proxmox. Die benutzerfreundliche Schnittstelle vereinfacht die Verwaltung und Konfiguration von Backups.
Um eine EC2-Instanz mit Vinchin Backup & Recovery zu sichern, befolgen Sie diese Schritte:
1. Wählen Sie die zu sichernde EC2-Instanz aus.
2. Wählen Sie das Sicherungsziel aus.
3. Wählen Sie die Sicherungsdienststrategien aus.
4. Prüfen und einreichen Sie die Arbeit.
Starten Sie Ihre 60-tägige kostenlose Testversion von Vinchin Backup & Recovery, um die sicheren, ressourcenschonenden Backup-Lösungen kennenzulernen. Oder,kontaktieren Sie uns für einen auf Ihre IT-Anforderungen zugeschnittenen Plan.
Durch das Beheben potenzieller Probleme mit den oben genannten Schritten können Sie das Problem schnell beheben und wieder Zugriff auf Ihre Instanz erhalten. Denken Sie daran, gute Sicherheitspraktiken anzuwenden, wie zum Beispiel den Zugriff auf vertrauenswürdige IP-Adressen zu beschränken und Ihre Sicherheitsgruppe sowie Netzwerkeinstellungen regelmäßig zu überprüfen.
Teilen auf:
