SSH-Fehler beheben

In diesem Dokument werden häufige Fehler beschrieben, die beim Herstellen einer Verbindung zu VM-Instanzen über SSH auftreten können, Möglichkeiten zur Behebung von Fehlern und Methoden zur Diagnose fehlgeschlagener SSH-Verbindungen.

SSH-Fehlerbehebungstool

Mit dem Tool zur Fehlerbehebung für SSH können Sie ermitteln, warum eine SSH-Verbindung fehlgeschlagen ist. Das Tool zur Fehlerbehebung führt die folgenden Tests durch, um die Ursache für fehlgeschlagene SSH-Verbindungen zu prüfen:

  • Nutzerberechtigungen testen: Prüft, ob Sie die erforderlichen IAM-Berechtigungen zum Herstellen einer Verbindung zur VM über SSH haben.
  • Netzwerkverbindung testen: Prüft, ob die VM mit dem Netzwerk verbunden ist.
  • VM-Instanzstatus testen: Prüft den CPU-Status der VM, um festzustellen, ob die VM ausgeführt wird.
  • VPC-Einstellungstests: Prüft den Standard-SSH-Port.

Fehlerbehebungstool ausführen

Sie können die Google Cloud Console oder die Google Cloud CLI verwenden, um nach Netzwerkproblemen und Fehlern bei Nutzerberechtigungen zu suchen, die zu einem Fehler bei der SSH-Verbindung führen können.

Console

Wenn eine SSH-Verbindung fehlschlägt, haben Sie die Möglichkeit, die Verbindung wiederzuverwenden oder die Fehlerbehebung mit dem Tool zur Fehlerbehebung für SSH-Browser zu beheben.

Klicken Sie auf Fehlerbehebung, um das Tool zur Fehlerbehebung auszuführen.

Starten Sie das SSH-Fehlerbehebungstool.

gcloud

Führen Sie das Fehlerbehebungstool mit dem Befehl gcloud compute ssh aus:

gcloud compute ssh VM_NAME \
    --troubleshoot

Ersetzen Sie VM_NAME durch den Namen der VM, zu der Sie keine Verbindung herstellen können.

Das Tool fordert Sie auf, die Berechtigung zur Durchführung der Fehlerbehebungstests bereitzustellen.

Ergebnisse überprüfen

Führen Sie nach der Ausführung des Tools zur Fehlerbehebung die folgenden Schritte aus:

  1. Überprüfen Sie die Testergebnisse, um festzustellen, warum die SSH-Verbindung der VM nicht funktioniert.
  2. Beheben Sie SSH-Verbindungen, indem Sie die vom Tool bereitgestellten Schritte zur Fehlerbehebung ausführen.

  3. Versuchen Sie noch einmal, eine Verbindung zur VM herzustellen.

    Wenn die Verbindung nicht erfolgreich ist, versuchen Sie, den Fehler manuell zu beheben. Gehen Sie dazu so vor:

Häufige SSH-Fehler

Im Folgenden finden Sie Beispiele für häufige Fehler, die bei der Verwendung von SSH zur Verbindung mit Compute Engine-VMs auftreten können.

SSH im Browser-Fehler

Fehler 401 „Nicht autorisiert“

Der folgende Fehler kann auftreten, wenn Sie eine Verbindung zu Ihrer VM über den SSH-in-Browser der Google Cloud Console herstellen:

Unauthorized
Error 401

Dieser Fehler tritt auf, wenn Ihr Nutzer Teil einer Organisation ist, die innerhalb von Google Workspace verwaltet wird, und es eine aktive Einschränkung in der Workspace-Richtlinie gibt, die verhindert, dass Nutzer auf SSH im Browser und die serielle Console in Google Cloud zugreifen.

Bitten Sie zur Behebung dieses Problems einen Google Workspace-Administrator, Folgendes zu tun:

  1. Prüfen Sie, ob Google Cloud für die Organisation aktiviert ist.

    Wenn Google Cloud deaktiviert ist, aktivieren Sie es und wiederholen Sie die Verbindung.

  2. Prüfen Sie, ob Dienste, die nicht einzeln gesteuert werden, aktiviert sind.

    Wenn diese Dienste deaktiviert sind, aktivieren Sie sie und wiederholen Sie die Verbindung.

Wenn das Problem nach dem Aktivieren der Google Cloud-Einstellungen in Google Workspace weiterhin besteht, gehen Sie so vor:

  1. Erfassen Sie den Netzwerktraffic in einer HTTP-Archivdatei (HAR), beginnend ab dem Start der SSH-Verbindung im Browser.

  2. Erstellen Sie einen Cloud Customer Care-Fall und hängen Sie die HAR-Datei an.

Keine Verbindung, neuer Versuch...

Der folgende Fehler kann auftreten, wenn Sie eine SSH-Sitzung starten: 

Could not connect, retrying ...

Screenshot: Keine Verbindung, neuer Versuch

So beheben Sie das Problem:

  1. Nachdem die VM gestartet wurde, wiederholen Sie die Verbindung. Wenn die Verbindung nicht erfolgreich ist, prüfen Sie mit dem folgenden Befehl, ob die VM nicht im Notfallmodus gestartet wurde:

    gcloud compute instances get-serial-port-output VM_NAME \
| grep "emergency mode"

    Wenn die VM im Notfallmodus startet, beheben Sie den VM-Startvorgang, um zu ermitteln, wo der Bootvorgang fehlschlägt.

  2. Prüfen Sie, ob der Dienst google-guest-agent.service ausgeführt wird. Führen Sie dazu den folgenden Befehl in der seriellen Konsole aus.

    systemctl status google-guest-agent.service

    Wenn der Dienst deaktiviert ist, aktivieren und starten Sie den Dienst mithilfe der folgenden Befehle:

    systemctl enable google-guest-agent.service
systemctl start google-guest-agent.service

  3. Prüfen Sie, ob die Linux-Agent-Skripts installiert sind und ausgeführt werden. Weitere Informationen finden Sie unter Status des Google-Agent ermitteln. Wenn der Linux-Google-Agent nicht installiert ist, installieren Sie ihn neu.

  4. Prüfen Sie, ob Sie die erforderlichen Rollen zum Herstellen einer Verbindung zur VM haben. Wenn Ihre VM OS Login verwendet, finden Sie weitere Informationen unter IAM-Rolle für OS Login zuweisen. Wenn die VM nicht OS Login verwendet, benötigen Sie die Rolle „Compute-Instanzadministrator“ oder die Rolle „Dienstkontonutzer“, wenn die VM für die Ausführung als Dienstkonto dienen soll. Die Rollen werden benötigt, um die SSH-Schlüsselmetadaten der Instanz oder des Projekts zu aktualisieren.

  5. Prüfen Sie mit dem folgenden Befehl, ob eine Firewallregel den SSH-Zugriff zulässt:

    gcloud compute firewall-rules list | grep "tcp:22"

  6. Prüfen Sie, ob eine Standardroute zum Internet (oder zum Bastion Host) vorhanden ist. Weitere Informationen finden Sie unter Routen prüfen.

  7. Achten Sie darauf, dass auf dem Root-Volume Speicherplatz vorhanden ist. Weitere Informationen finden Sie unter Fehlerbehebung bei vollen Laufwerken und beim Anpassen der Größe von Laufwerken.

  8. Prüfen Sie mit dem folgenden Befehl, ob die VM nicht über genügend Arbeitsspeicher verfügt:

    gcloud compute instances get-serial-port-output instance-name \
| grep "Out of memory: Kill process" - e "Kill process" -e "Memory cgroup out of memory" -e "oom"

    Wenn nicht genügend Arbeitsspeicher vorhanden ist, stellen Sie eine Verbindung zur seriellen Konsole her, um den Fehler zu beheben.

Linux-Fehler

Berechtigung verweigert (publickey)

Der folgende Fehler kann auftreten, wenn Sie eine Verbindung zu Ihrer VM herstellen:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Dieser Fehler kann aus verschiedenen Gründen auftreten. Das sind die häufigsten Ursachen für diesen Fehler:

  • Sie haben einen in den Metadaten gespeicherten SSH-Schlüssel verwendet, um eine Verbindung zu einer VM herzustellen, bei der OS Login aktiviert ist. Wenn OS Login in Ihrem Projekt aktiviert ist, akzeptiert Ihre VM keine SSH-Schlüssel, die in Metadaten gespeichert sind. Wenn Sie nicht sicher sind, ob OS Login aktiviert ist, lesen Sie die Informationen unter Prüfen, ob OS Login konfiguriert ist.

    Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:

  • Sie haben einen SSH-Schlüssel verwendet, der in einem OS Login-Profil gespeichert ist, um eine Verbindung zu einer VM herzustellen, bei der OS Login nicht aktiviert ist. Wenn Sie OS Login deaktivieren, akzeptiert Ihre VM keine SSH-Schlüssel, die in Ihrem OS Login-Profil gespeichert wurden. Wenn Sie nicht sicher sind, ob OS Login aktiviert ist, lesen Sie die Informationen unter Prüfen, ob OS Login konfiguriert ist.

    Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:

  • Die VM ist OS Login aktiviert, Sie haben jedoch nicht genügend IAM-Berechtigungen, um OS Login zu verwenden. Zum Herstellen einer Verbindung zu einer VM, für die OS Login aktiviert ist, benötigen Sie die für OS Login erforderlichen Berechtigungen. Wenn Sie nicht sicher sind, ob OS Login aktiviert ist, lesen Sie die Informationen unter Prüfen, ob OS Login konfiguriert ist.

    Gewähren Sie die erforderlichen IAM-Rollen für OS Login, um dieses Problem zu beheben.

  • Ihr Schlüssel ist abgelaufen und Compute Engine hat die Datei ~/.ssh/authorized_keys gelöscht. Wenn Sie Ihrer VM manuell SSH-Schlüssel hinzugefügt und dann über die Google Cloud Console eine Verbindung zu Ihrer VM hergestellt haben, hat Compute Engine ein neues Schlüsselpaar für Ihre Verbindung erstellt. Nach dem Ablauf des neuen Schlüsselpaars hat Compute Engine Ihre ~/.ssh/authorized_keys-Datei in der VM gelöscht, die Ihren manuell hinzugefügten SSH-Schlüssel enthielt.

    Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:

  • Die Verbindung wurde mit einem Drittanbietertool hergestellt und der SSH-Befehl ist falsch konfiguriert. Wenn Sie eine Verbindung mit dem Befehl ssh herstellen, aber keinen Pfad zum privaten Schlüssel angeben oder einen falschen Pfad zum privaten Schlüssel angeben, lehnt die VM Ihre Verbindung ab.

    Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:

    • Führen Sie dazu diesen Befehl aus:
      ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP

      Ersetzen Sie Folgendes:
      • PATH_TO_PRIVATE_KEY ist der Pfad zur privaten SSH-Schlüsseldatei.
      • USERNAME ist der Name des Nutzers, der eine Verbindung zur Instanz herstellt. Wenn Sie Ihre SSH-Schlüssel in Metadaten verwalten, muss dies der Nutzername sein, den Sie beim Erstellen des SSH-Schlüssels angegeben haben. Für OS Login-Konten wird der Nutzername in Ihrem Google-Profil festgelegt.
      • EXTERNAL_IP ist die externe IP-Adresse für Ihre Instanz.
    • Stellen Sie über die Google Cloud Console oder die Google Cloud CLI eine Verbindung zu Ihrer VM her. Wenn Sie über diese Tools eine Verbindung herstellen, verwaltet Compute Engine die Schlüsselerstellung für Sie. Weitere Informationen finden Sie unter Verbindung zu VMs herstellen.

  • Die Gastumgebung Ihrer VM wird nicht ausgeführt. Wenn Sie sich zum ersten Mal mit Ihrer VM verbinden und die Gastumgebung nicht ausgeführt wird, lehnt die VM möglicherweise die SSH-Verbindungsanfrage ab.

    So beheben Sie das Problem:

    1. Starten Sie die VM neu.
    2. Prüfen Sie in der Google Cloud Console die Systemstartlogs in der Ausgabe des seriellen Ports, um festzustellen, ob die Gastumgebung ausgeführt wird. Weitere Informationen finden Sie unter Gastumgebung validieren.
    3. Wenn die Gastumgebung nicht ausgeführt wird, installieren Sie die Gastumgebung manuell, indem Sie das Bootlaufwerk der VM klonen und ein Startskript verwenden.

  • Der OpenSSH-Daemon (sshd) wird nicht ordnungsgemäß ausgeführt oder konfiguriert. Der sshd bietet über das SSH-Protokoll einen sicheren Remotezugriff auf das System. Ist er falsch konfiguriert oder wird nicht ausgeführt, können Sie keine Verbindung über SSH zur VM herstellen.

    Versuchen Sie Folgendes (eines davon oder mehr) um dieses Problem zu beheben:

    • Prüfen Sie anhand des Benutzerhandbuchs für Ihr Betriebssystem, ob sshd_config korrekt eingerichtet ist.

    • Sie benötigen die erforderlichen Inhaber- und Berechtigungseinstellungen für Folgendes:

      • $HOME- und $HOME/.ssh-Verzeichnisse
      • Datei $HOME/.ssh/authorized_keys

      Eigentümer

      Die Gastumgebung speichert autorisierte öffentliche SSH-Schlüssel in der Datei $HOME/.ssh/authorized_keys. Der Inhaber der Verzeichnisse $HOME und $HOME/.ssh sowie der Datei $HOME/.ssh/authorized_keys muss mit dem Nutzer übereinstimmen, der eine Verbindung zur VM herstellt.

      Berechtigungen

      Die Gastumgebung benötigt die folgenden Linux-Berechtigungen:

      Pfad Berechtigungen
      /home 0755
      $HOME 0700 oder 0750 oder 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Um herauszufinden, welche der Optionen die richtige Standardberechtigung für Ihr $HOME-Verzeichnis ist, sehen Sie in der offiziellen Dokumentation für Ihre spezielle Linux-Distribution nach.

      Alternativ können Sie eine neue VM erstellen, die auf demselben Image basiert, und deren Standardberechtigungen für $HOME prüfen.

      Informationen zum Ändern von Berechtigungen und Inhaberschaft finden Sie unter chmod und chown.

    • Starten Sie die sshd mit dem folgenden Befehl neu:

      systemctl restart sshd.service

      Prüfen Sie mit dem folgenden Befehl, ob es Fehler im Status gibt:

      systemctl status sshd.service

      Die Statusausgabe kann Informationen wie den Exit-Code oder den Grund für den Fehler enthalten. Diese Details können Sie für die weitere Fehlerbehebung verwenden.

  • Das Bootlaufwerk der VM ist voll. Wenn eine SSH-Verbindung hergestellt wird, fügt die Gastumgebung den öffentlichen SSH-Schlüssel der Sitzung der Datei ~/.ssh/authorized_keys hinzu. Wenn das Laufwerk voll ist, schlägt die Verbindung fehl.

    Tun Sie Folgendes (eines davon oder mehr) um dieses Problem zu beheben:

  • Die Berechtigungen oder Eigentümerschaften für $HOME, $HOME/.ssh oder $HOME/.ssh/authorized_keys sind falsch.

    Eigentümer

    Die Gastumgebung speichert autorisierte öffentliche SSH-Schlüssel in der Datei $HOME/.ssh/authorized_keys. Der Inhaber der Verzeichnisse $HOME und $HOME/.ssh sowie der Datei $HOME/.ssh/authorized_keys muss mit dem Nutzer übereinstimmen, der eine Verbindung zur VM herstellt.

    Berechtigungen

    Die Gastumgebung benötigt die folgenden Linux-Berechtigungen:

    Pfad Berechtigungen
    /home 0755
    $HOME 0700 oder 0750 oder 0755 *
    $HOME/.ssh 0700
    $HOME/.ssh/authorized_keys 0600

    * Um herauszufinden, welche der Optionen die richtige Standardberechtigung für Ihr $HOME-Verzeichnis ist, sehen Sie in der offiziellen Dokumentation für Ihre spezielle Linux-Distribution nach.

    Alternativ können Sie eine neue VM erstellen, die auf demselben Image basiert, und deren Standardberechtigungen für $HOME prüfen.

    Informationen zum Ändern von Berechtigungen und Inhaberschaft finden Sie unter chmod und chown.

Verbindungsfehler

Die folgenden Fehler können auftreten, wenn Sie über die Google Cloud Console, die gcloud CLI, einen Bastion Host oder einen lokalen Client eine Verbindung zur VM herstellen:

  • Die Google Cloud Console

    Connection Failed

We are unable to connect to the VM on port 22.

  • Die gcloud CLI-Befehlszeile:

    ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].

  • Ein Bastion Host oder ein lokaler Client:

    port 22: Connection timed out.

    port 22: Connection refused

Diese Fehler können aus verschiedenen Gründen auftreten. Im Folgenden finden Sie einige der häufigsten Ursachen dafür:

  • Die VM wird gestartet und sshd wird noch nicht ausgeführt. Sie können keine Verbindung zu einer VM herstellen, bevor diese ausgeführt wird.

    Lösung: Warten Sie, bis die VM gestartet wurde und versuchen Sie dann noch einmal, eine Verbindung herzustellen.

  • sshd wird auf einem benutzerdefinierten Port ausgeführt. Wenn Sie sshd für die Ausführung auf einem anderen Port als Port 22 konfiguriert haben, können Sie keine Verbindung zu Ihrer VM herstellen.

    Lösung: Erstellen Sie eine benutzerdefinierte Firewallregel, die tcp-Traffic auf dem Port zulässt, auf dem Ihr sshd mit dem folgenden Befehl ausgeführt wird:

    gcloud compute firewall-rules create FIREWALL_NAME \
  --allow tcp:PORT_NUMBER

    Weitere Informationen zum Erstellen benutzerdefinierter Firewallregeln finden Sie unter Firewallregeln erstellen.

  • Die SSH-Firewallregel fehlt oder lässt keinen Traffic von IAP oder dem öffentlichen Internet zu. SSH-Verbindungen werden abgelehnt, wenn Firewallregeln keine Verbindungen aus IAP oder dem eingehenden TCP-Traffic für den IP-Bereich 0.0.0.0/0 zulassen.

    Führen Sie einen der folgenden Schritte aus, um das Problem zu lösen:

    • Wenn Sie Identity-Aware Proxy (IAP) für die TCP-Weiterleitung verwenden, aktualisieren Sie Ihre benutzerdefinierte Firewallregel, um Traffic von IAP anzunehmen, und prüfen Sie dann Ihre IAM-Berechtigungen.

      1. Aktualisieren Sie Ihre benutzerdefinierte Firewallregel, um Traffic von 35.235.240.0/20 zuzulassen, dem IP-Adressbereich, den IAP für die TCP-Weiterleitung verwendet. Weitere Informationen finden Sie unter Firewallregel erstellen.
      2. Weisen Sie Berechtigungen zur Verwendung der IAP-TCP-Weiterleitung zu, wenn nicht bereits geschehen.

    • Wenn Sie IAP nicht verwenden, aktualisieren Sie Ihre benutzerdefinierte Firewallregel, um eingehenden SSH-Traffic zuzulassen.

      1. Aktualisieren Sie Ihre benutzerdefinierte Firewallregel auf Eingehende SSH-Verbindungen zu VMs zulassen.

  • Die SSH-Verbindung ist nach dem Upgrade des VM-Kernels fehlgeschlagen. Bei einer VM kann es nach einem Kernelupdate zu einer Kernel Panic kommen, wodurch die VM nicht mehr zugänglich ist.

    So beheben Sie das Problem:

    1. Stellen Sie das Laufwerk auf einer anderen VM bereit.
    2. Aktualisieren Sie die Datei grub.cfg, um die vorherige Version des Kernels zu verwenden.
    3. Hängen Sie das Laufwerk an die nicht reagierende VM an.
    4. Prüfen Sie mit dem Befehl gcloud compute instances describe, ob der Status der VM RUNNING lautet.
    5. Installieren Sie den Kernel neu.
    6. Starten Sie die VM neu.

    Wenn Sie vor dem Upgrade der VM einen Snapshot des Bootlaufwerks erstellt haben, verwenden Sie alternativ den Snapshot zum Erstellen einer VM.

  • Der OpenSSH-Daemon (sshd) wird nicht ordnungsgemäß ausgeführt oder konfiguriert. Der sshd bietet über das SSH-Protokoll einen sicheren Remotezugriff auf das System. Ist er falsch konfiguriert oder wird nicht ausgeführt, können Sie keine Verbindung über SSH zur VM herstellen.

    Versuchen Sie Folgendes (eines davon oder mehr) um dieses Problem zu beheben:

    • Prüfen Sie anhand des Benutzerhandbuchs für Ihr Betriebssystem, ob sshd_config korrekt eingerichtet ist.

    • Sie benötigen die erforderlichen Inhaber- und Berechtigungseinstellungen für Folgendes:

      • $HOME- und $HOME/.ssh-Verzeichnisse
      • Datei $HOME/.ssh/authorized_keys

      Eigentümer

      Die Gastumgebung speichert autorisierte öffentliche SSH-Schlüssel in der Datei $HOME/.ssh/authorized_keys. Der Inhaber der Verzeichnisse $HOME und $HOME/.ssh sowie der Datei $HOME/.ssh/authorized_keys muss mit dem Nutzer übereinstimmen, der eine Verbindung zur VM herstellt.

      Berechtigungen

      Die Gastumgebung benötigt die folgenden Linux-Berechtigungen:

      Pfad Berechtigungen
      /home 0755
      $HOME 0700 oder 0750 oder 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Um herauszufinden, welche der Optionen die richtige Standardberechtigung für Ihr $HOME-Verzeichnis ist, sehen Sie in der offiziellen Dokumentation für Ihre spezielle Linux-Distribution nach.

      Alternativ können Sie eine neue VM erstellen, die auf demselben Image basiert, und deren Standardberechtigungen für $HOME prüfen.

      Informationen zum Ändern von Berechtigungen und Inhaberschaft finden Sie unter chmod und chown.

    • Starten Sie die sshd mit dem folgenden Befehl neu:

      systemctl restart sshd.service

      Prüfen Sie mit dem folgenden Befehl, ob es Fehler im Status gibt:

      systemctl status sshd.service

      Die Statusausgabe kann Informationen wie den Exit-Code oder den Grund für den Fehler enthalten. Diese Details können Sie für die weitere Fehlerbehebung verwenden.

  • Die VM wird nicht gestartet und Sie können keine Verbindung über SSH oder die serielle Konsole herstellen. Wenn die VM nicht zugänglich ist, ist Ihr Betriebssystem möglicherweise beschädigt. Wenn das Bootlaufwerk nicht gestartet wird, können Sie das Problem diagnostizieren. Informationen zum Wiederherstellen der beschädigten VM und zum Abrufen von Daten finden Sie unter Beschädigte VM oder vollständiges Bootlaufwerk wiederherstellen.

  • Die VM wird im Wartungsmodus gestartet. Beim Booten im Wartungsmodus akzeptiert die VM keine SSH-Verbindungen. Sie können jedoch eine Verbindung zur seriellen Konsole der VM herstellen und sich als Root-Nutzer anmelden.

    So beheben Sie das Problem:

    1. Wenn Sie kein Root-Passwort für die VM festgelegt haben, verwenden Sie ein Metadaten-Startskript, um während des Starts den folgenden Befehl auszuführen:

      echo "root:NEW_PASSWORD" | chpasswd

      Ersetzen Sie NEW_PASSWORD durch ein Passwort Ihrer Wahl.

    2. Starten Sie die VM neu.

    3. Stellen Sie eine Verbindung zur seriellen Konsole der VM her und melden Sie sich als Root-Nutzer an.

Unerwarteter Fehler

Der folgende Fehler kann auftreten, wenn Sie versuchen, eine Verbindung zu einer Linux-VM herzustellen:

Connection Failed
You cannot connect to the VM instance because of an unexpected error. Wait a few moments and then try again.

Dieses Problem kann verschiedene Ursachen haben. Im Folgenden finden Sie einige der häufigsten Ursachen dafür:

  • Der OpenSSH-Daemon (sshd) wird nicht ordnungsgemäß ausgeführt oder konfiguriert. Der sshd bietet über das SSH-Protokoll einen sicheren Remotezugriff auf das System. Ist er falsch konfiguriert oder wird nicht ausgeführt, können Sie keine Verbindung über SSH zur VM herstellen.

    Versuchen Sie Folgendes (eines davon oder mehr) um dieses Problem zu beheben:

    • Prüfen Sie anhand des Benutzerhandbuchs für Ihr Betriebssystem, ob sshd_config korrekt eingerichtet ist.

    • Sie benötigen die erforderlichen Inhaber- und Berechtigungseinstellungen für Folgendes:

      • $HOME- und $HOME/.ssh-Verzeichnisse
      • Datei $HOME/.ssh/authorized_keys

      Eigentümer

      Die Gastumgebung speichert autorisierte öffentliche SSH-Schlüssel in der Datei $HOME/.ssh/authorized_keys. Der Inhaber der Verzeichnisse $HOME und $HOME/.ssh sowie der Datei $HOME/.ssh/authorized_keys muss mit dem Nutzer übereinstimmen, der eine Verbindung zur VM herstellt.

      Berechtigungen

      Die Gastumgebung benötigt die folgenden Linux-Berechtigungen:

      Pfad Berechtigungen
      /home 0755
      $HOME 0700 oder 0750 oder 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Um herauszufinden, welche der Optionen die richtige Standardberechtigung für Ihr $HOME-Verzeichnis ist, sehen Sie in der offiziellen Dokumentation für Ihre spezielle Linux-Distribution nach.

      Alternativ können Sie eine neue VM erstellen, die auf demselben Image basiert, und deren Standardberechtigungen für $HOME prüfen.

      Informationen zum Ändern von Berechtigungen und Inhaberschaft finden Sie unter chmod und chown.

    • Starten Sie die sshd mit dem folgenden Befehl neu:

      systemctl restart sshd.service

      Prüfen Sie mit dem folgenden Befehl, ob es Fehler im Status gibt:

      systemctl status sshd.service

      Die Statusausgabe kann Informationen wie den Exit-Code oder den Grund für den Fehler enthalten. Diese Details können Sie für die weitere Fehlerbehebung verwenden.

  • Unbekanntes Problem mit dem SSH-Daemon Wenn Sie ein unbekanntes Problem mit dem SSH-Daemon diagnostizieren möchten, prüfen Sie die Logs der seriellen Konsole auf Fehler.

    Versuchen Sie je nach Ausgabe der Logs der seriellen Konsole, die VM zu löschen und die Probleme mit dem SSH-Daemon zu beheben:

    1. Hängen Sie das Laufwerk an eine andere Linux-VM an.
    2. Stellen Sie eine Verbindung zur VM her, auf der das Laufwerk bereitgestellt ist.
    3. Stellen Sie das Laufwerk im Betriebssystem auf ein Verzeichnis MOUNT_DIR in der VM bereit.
    4. Prüfen Sie die SSH-bezogenen Logs /var/log/secure oder /var/log/auth.log auf Probleme/Fehler. Beheben Sie die Probleme, sofern möglich. Andernfalls erstellen Sie einen Supportfall und hängen Sie die Protokolle an.

    5. Heben Sie die Bereitstellung des Laufwerks auf dem Betriebssystem mit dem Befehl umount auf:

      cd ~/
umount /mnt

    6. Trennen Sie das Laufwerk von der VM.

    7. Hängen Sie das Laufwerk an die ursprüngliche VM an.

    8. Starten Sie die VM.

Verbindung zum Backend konnte nicht hergestellt werden

Die folgenden Fehler können auftreten, wenn Sie über die Google Cloud Console oder die gcloud CLI eine Verbindung zur VM herstellen:

  • Die Google Cloud Console

    -- Connection via Cloud Identity-Aware Proxy Failed

-- Code: 4003

-- Reason: failed to connect to backend

  • Die gcloud CLI-Befehlszeile:

    ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: 'failed to connect to backend'].

Diese Fehler treten auf, wenn Sie versuchen, mithilfe von SSH eine Verbindung zu einer VM herzustellen, die keine öffentliche IP-Adresse hat und bei der Sie Identity-Aware Proxy nicht auf Port 22 konfiguriert haben.

Lösung: Erstellen Sie eine Firewallregel auf Port 22, die eingehenden Traffic von Identity-Aware Proxy zulässt.

Hostschlüssel stimmt nicht überein

Der folgende Fehler kann auftreten, wenn Sie eine Verbindung zu Ihrer VM herstellen:

Host key for server IP_ADDRESS does not match

Dieser Fehler tritt auf, wenn der Hostschlüssel in der Datei ~/.ssh/known_hosts nicht mit dem Hostschlüssel der VM übereinstimmt.

Löschen Sie den Hostschlüssel aus der Datei ~/.ssh/known_hosts und versuchen Sie dann noch einmal, die Verbindung herzustellen, um dieses Problem zu beheben.

Metadatenwert ist zu groß

Der folgende Fehler kann auftreten, wenn Sie versuchen, einen neuen SSH-Schlüssel zu Metadaten hinzuzufügen:

ERROR:"Value for field 'metadata.items[X].value' is too large: maximum size 262144 character(s); actual size NUMBER_OF_CHARACTERS."

Metadatenwerte haben ein maximales Limit von 256 KB. Führen Sie einen der folgenden Schritte aus, um diese Einschränkung zu umgehen:

Windows-Fehler

Berechtigung verweigert; bitte noch einmal versuchen

Der folgende Fehler kann auftreten, wenn Sie eine Verbindung zu Ihrer VM herstellen:

USERNAME@compute.INSTANCE_ID's password:
Permission denied, please try again.

Dieser Fehler gibt an, dass der Nutzer, der versucht, eine Verbindung zur VM herzustellen, auf der VM nicht vorhanden ist. Dies sind einige der häufigsten Ursachen für diesen Fehler:

  • Ihre Version der gcloud CLI ist veraltet.

    Wenn die gcloud CLI veraltet ist, versuchen Sie möglicherweise, eine Verbindung mit einem nicht konfigurierten Nutzernamen herzustellen. Aktualisieren Sie die gcloud CLI, um dieses Problem zu beheben.

  • Sie haben versucht, eine Verbindung zu einer Windows-VM herzustellen, für die SSH nicht aktiviert ist.

    Zur Behebung dieses Fehlers legen Sie für den Schlüssel enable-windows-ssh in den Projekt- oder Instanzmetadaten den Wert TRUE fest. Weitere Informationen zum Festlegen von Metadaten finden Sie unter Benutzerdefinierte Metadaten festlegen.

Berechtigung verweigert (publickey,keyboard-interactive)

Der folgende Fehler kann auftreten, wenn Sie eine Verbindung zu einer VM herstellen, für die SSH nicht aktiviert ist:

Permission denied (publickey,keyboard-interactive).

Zur Behebung dieses Fehlers legen Sie für den Schlüssel enable-windows-ssh in den Projekt- oder Instanzmetadaten den Wert TRUE fest. Weitere Informationen zum Festlegen von Metadaten finden Sie unter Benutzerdefinierte Metadaten festlegen.

SSH-Verbindung zur Instanz konnte nicht hergestellt werden

Der folgende Fehler kann auftreten, wenn Sie eine Verbindung zur VM über die gcloud CLI herstellen:

ERROR: (gcloud.compute.ssh) Could not SSH into the instance.
It is possible that your SSH key has not propagated to the instance yet.
Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.

Dieser Fehler kann aus verschiedenen Gründen auftreten. Im Folgenden finden Sie einige der häufigsten Ursachen dafür:

  • Sie haben versucht, eine Verbindung zu einer Windows-VM herzustellen, auf der SSH nicht installiert ist.

    Folgen Sie der Anleitung unter SSH für Windows auf einer ausgeführten VM aktivieren, um dieses Problem zu beheben.

  • Der OpenSSH-Server (sshd) wird nicht ordnungsgemäß ausgeführt oder konfiguriert. Der sshd bietet über das SSH-Protokoll einen sicheren Remotezugriff auf das System. Ist er falsch konfiguriert oder wird nicht ausgeführt, können Sie keine Verbindung über SSH zur VM herstellen.

    Prüfen Sie zum Beheben dieses Problems die OpenSSH-Serverkonfiguration für Windows Server und Windows, um sicherzustellen, dass sshd ordnungsgemäß eingerichtet ist.

Zeitüberschreitung der Verbindung

Zeitüberschreitungen von SSH-Verbindungen können folgende Ursachen haben:

  • Das Booten der VM wurde nicht abgeschlossen. Warten Sie kurz, bis die VM gebootet wurde.

    Lösung: Warten Sie, bis die VM gestartet wurde und versuchen Sie dann noch einmal, eine Verbindung herzustellen.

  • Das SSH-Paket ist nicht installiert. Bei Windows-VMs müssen Sie das Paket google-compute-engine-ssh installieren, bevor Sie eine Verbindung über SSH herstellen können.

    Installieren Sie das SSH-Paket, um dieses Problem zu beheben.

Fehlgeschlagene SSH-Verbindungen diagnostizieren

In den folgenden Abschnitten werden die Schritte beschrieben, die Sie ausführen können, um die Ursache fehlerhafter SSH-Verbindungen zu diagnostizieren und diese Fehler zu beheben.

Gehen Sie folgendermaßen vor, bevor Sie fehlgeschlagene SSH-Verbindungen diagnostizieren:

Diagnosemethoden für Linux- und Windows-VMs

Verbindung testen

Es kann vorkommen, dass Sie aufgrund von Verbindungsproblemen, die mit Firewalls, Netzwerkverbindungen oder dem Nutzerkonto zusammenhängen, keine SSH-Verbindung zu einer VM-Instanz herstellen können. Die Schritte dieses Abschnitts bieten die Möglichkeit, die jeweiligen Ursachen für die Verbindungsprobleme zu ermitteln.

Firewallregeln prüfen

Compute Engine stellt für jedes Projekt eine Gruppe standardmäßiger Firewallregeln bereit, die Traffic über SSH erlauben. Wenn Sie nicht auf die Instanz zugreifen können, prüfen Sie mit dem gcloud compute-Befehlszeilentool Ihre Liste der Firewalls und achten Sie darauf, dass die Regel default-allow-ssh vorhanden ist.

Führen Sie auf Ihrer lokalen Workstation den folgenden Befehl aus:

gcloud compute firewall-rules list

Sollte die Regel fehlen, fügen Sie sie wieder hinzu:

gcloud compute firewall-rules create default-allow-ssh \
    --allow tcp:22

Verwenden Sie den Befehl gcloud compute firewall-rules describe, um sich alle Daten anzeigen zu lassen, die mit der Firewallregel default-allow-ssh in Ihrem Projekt verknüpft sind:

gcloud compute firewall-rules describe default-allow-ssh \
    --project=project-id

Weitere Informationen zu Firewallregeln finden Sie unter Firewallregeln in Google Cloud.

Netzwerkverbindung testen

Testen Sie den TCP-Handshake, um festzustellen, ob die Netzwerkverbindung funktioniert:

  1. Rufen Sie die externe natIP für Ihre VM ab:

    gcloud compute instances describe VM_NAME \
    --format='get(networkInterfaces[0].accessConfigs[0].natIP)'

    Ersetzen Sie VM_NAME durch den Namen der VM, zu der Sie keine Verbindung herstellen können.

  2. Testen Sie die Netzwerkverbindung zu Ihrer VM von Ihrer Workstation aus:

    Linux, Windows 2019/2022 und macOS 

    curl -vso /dev/null --connect-timeout 5 EXTERNAL_IP:PORT_NUMBER

    Dabei gilt:

    • EXTERNAL_IP: die externe IP-Adresse, die Sie im vorherigen Schritt abgerufen haben
    • PORT_NUMBER: die Portnummer

    Wenn der TCP-Handshake erfolgreich ist, sieht die Ausgabe in etwa so aus:

    Expire in 0 ms for 6 (transfer 0x558b3289ffb0)
Expire in 5000 ms for 2 (transfer 0x558b3289ffb0)
Trying 192.168.0.4...
TCP_NODELAY set
Expire in 200 ms for 4 (transfer 0x558b3289ffb0)
Connected to 192.168.0.4 (192.168.0.4) port 443 (#0)
> GET / HTTP/1.1
> Host: 192.168.0.4:443
> User-Agent: curl/7.64.0
> Accept: */*
>
Empty reply from server
Connection #0 to host 192.168.0.4 left intact

    Die Zeile Connected to zeigt einen erfolgreichen TCP-Handshake an.

    Windows 2012 und 2016 

    PS C:> New-Object System.Net.Sockets.TcpClient('EXTERNAL_IP',PORT_NUMBER)

    Dabei gilt:

    • EXTERNAL_IP: die externe IP-Adresse, die Sie im vorherigen Schritt erhalten haben
    • PORT_NUMBER: die Portnummer

    Wenn der TCP-Handshake erfolgreich ist, sieht die Ausgabe in etwa so aus:

    Available           : 0
Client              : System.Net.Sockets.Socket
Connected           : True
ExclusiveAddressUse : False
ReceiveBufferSize   : 131072
SendBufferSize      : 131072
ReceiveTimeout      : 0
SendTimeout         : 0
LingerState         : System.Net.Sockets.LingerOption
NoDelay             : False

    Die Zeile Connected: True zeigt einen erfolgreichen TCP-Handshake an.

Wenn der TCP-Handshake erfolgreich abgeschlossen wurde, wird die Verbindung nicht durch eine Software-Firewall-Regel blockiert, das Betriebssystem leitet die Pakete korrekt weiter und ein Server überwacht den Zielport. Wenn der TCP-Handshake erfolgreich abgeschlossen wurde, die VM jedoch keine SSH-Verbindungen akzeptiert, ist der Daemon sshd möglicherweise falsch konfiguriert oder wird nicht ordnungsgemäß ausgeführt. Prüfen Sie anhand des Benutzerhandbuchs für Ihr Betriebssystem, ob sshd_config korrekt eingerichtet ist.

Um Konnektivitätstests zur Analyse der VPC-Netzwerkpfadkonfiguration zwischen zwei VMs auszuführen und zu prüfen, ob die programmierte Konfiguration den Traffic zulassen sollte, beachten Sie Auf falsch konfigurierte Firewallregeln in Google Cloud prüfen.

Nutzer für eine Verbindung ändern

Eine fehlgeschlagene Anmeldung ist möglicherweise auf das verwendete Nutzerkonto zurückzuführen. Es kann beispielsweise sein, dass die Berechtigungen in der Datei ~/.ssh/authorized_keys der Instanz für den Nutzer nicht ordnungsgemäß festgelegt wurden.

Melden Sie sich zur Klärung mit der gcloud CLI als ein anderer Nutzer an. Ersetzen Sie dabei in der SSH-Anfrage ANOTHER_USERNAME durch einen anderen Nutzernamen. Die gcloud CLI aktualisiert die Metadaten des Projekts, um den neuen Nutzer hinzuzufügen und den SSH-Zugriff zuzulassen.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Dabei gilt:

  • ANOTHER_USERNAME ist ein Nutzername, der nicht Ihr eigener Nutzername ist.
  • VM_NAME ist der Name der VM, zu der Sie eine Verbindung herstellen möchten.

Fehler mit der seriellen Konsole beheben

Wir empfehlen Ihnen, die Logs der seriellen Konsole auf Verbindungsfehler zu prüfen. Auf die serielle Konsole können Sie als Root-Nutzer von Ihrer lokalen Workstation aus mit einem Browser zugreifen. Diese Vorgehensweise ist hilfreich, wenn eine Anmeldung mit SSH nicht möglich ist oder die Instanz keine Verbindung zum Netzwerk hat. Die serielle Konsole ist in beiden Situationen zugänglich.

So melden Sie sich in der seriellen Konsole der VM an und beheben Probleme mit der VM:

  1. Aktivieren Sie den interaktiven Zugriff auf die serielle Konsole der VM.

  2. Ändern Sie bei Linux-VMs das Root-Passwort und fügen Sie der VM das folgende Startskript hinzu: 

    echo root:PASSWORD | chpasswd

    Ersetzen Sie PASSWORD durch ein Passwort Ihrer Wahl.

  3. Über die serielle Konsole stellen Sie eine Verbindung zur VM her.

  4. Deaktivieren Sie bei Linux-VMs die Root-Konto-Login, nachdem Sie alle Fehler behoben haben: 

    sudo passwd -l root

Diagnosemethoden für Linux-VMs

VM-Instanz ohne Herunterfahren prüfen

Es kann sein, dass Sie keine Verbindung zu einer Instanz herstellen können, obwohl sie Produktionstraffic weiterhin fehlerfrei verarbeitet. In einer solchen Situation müssen Sie das Laufwerk prüfen, ohne die Instanz zu unterbrechen.

So prüfen und reparieren Sie das Laufwerk:

  1. Sichern Sie das Bootlaufwerk dadurch, dass Sie einen Snapshot des Laufwerks erstellen.
  2. Erstellen Sie anhand dieses Snapshots einen regulären nichtflüchtigen Speicher.
  3. Erstellen Sie eine temporäre Instanz.
  4. Hängen Sie den regulären nichtflüchtigen Speicher an Ihre neue temporäre Instanz an und stellen Sie ihn bereit.

Bei dieser Vorgehensweise entsteht ein isoliertes Netzwerk, das nur SSH-Verbindungen zulässt. Dadurch wird verhindert, dass unbeabsichtigte Folgen bei der Erstellung der geklonten Instanz Ihre Produktionsdienste beeinträchtigen.

  1. Erstellen Sie ein neues VPC-Netzwerk, in dem die geklonte Instanz gehostet werden kann:

    gcloud compute networks create debug-network

    Ersetzen Sie NETWORK_NAME durch den Namen für das neue Netzwerk.

  2. Fügen Sie eine Firewallregel hinzu, die SSH-Verbindungen zum Netzwerk zulässt:

    gcloud compute firewall-rules create debug-network-allow-ssh \
   --network debug-network \
   --allow tcp:22

  3. Erstellen Sie einen Snapshot des Bootlaufwerks.

    gcloud compute disks snapshot BOOT_DISK_NAME \
   --snapshot-names debug-disk-snapshot

    Ersetzen Sie BOOT_DISK_NAME durch den Namen des Bootlaufwerks.

  4. Erstellen Sie mit dem Snapshot aus dem vorigen Schritt ein neues Laufwerk:

    gcloud compute disks create example-disk-debugging \
   --source-snapshot debug-disk-snapshot

  5. Erstellen Sie eine neue Debug-Instanz ohne externe IP-Adresse:

    gcloud compute instances create debugger \
   --network debug-network \
   --no-address

  6. Fügen Sie der Instanz das Debug-Laufwerk hinzu:

    gcloud compute instances attach-disk debugger \
   --disk example-disk-debugging

  7. Folgen Sie der Anleitung zum Herstellen einer Verbindung zu einer VM über einen Bastion Host.

  8. Nach der Anmeldung bei der Debugger-Instanz führen Sie die Fehlerbehebung für die Instanz durch. Prüfen Sie zum Beispiel die Instanzlogs:

    sudo su -

    mkdir /mnt/VM_NAME

    mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/VM_NAME

    cd /mnt/VM_NAME/var/log

    # Identify the issue preventing ssh from working
ls

    Ersetzen Sie VM_NAME durch den Namen der VM, zu der Sie keine Verbindung herstellen können.

Startskript verwenden

Wenn keiner der vorherigen Vorschläge weitergeholfen hat, können Sie ein Startskript erstellen, um Informationen unmittelbar nach dem Start der Instanz zu erfassen. Folgen Sie der Anleitung zum Ausführen von Startskripts.

Anschließend müssen Sie mit gcloud compute instances reset die Instanz zurücksetzen, damit die Metadaten wirksam werden.

Alternativ können Sie die Instanz auch neu erstellen, indem Sie ein Diagnose-Startskript ausführen:

  1. Führen Sie gcloud compute instances delete mit dem Flag --keep-disks aus.

    gcloud compute instances delete VM_NAME \
   --keep-disks boot

    Ersetzen Sie VM_NAME durch den Namen der VM, zu der Sie keine Verbindung herstellen können.

  2. Fügen Sie eine neue Instanz mit demselben Laufwerk hinzu und geben Sie das Startskript an.

    gcloud compute instances create NEW_VM_NAME \
   --disk name=BOOT_DISK_NAME,boot=yes \
   --metadata startup-script-url URL

    Dabei gilt:

    • NEW_VM_NAME ist der Name der neuen VM, die Sie erstellen.
    • BOOT_DISK_NAME ist der Name des Bootlaufwerks von der VM, zu der Sie keine Verbindung herstellen können.
    • URL ist die Cloud Storage-URL zum Skript, entweder im Format gs://BUCKET/FILE oder https://storage.googleapis.com/BUCKET/FILE.

Laufwerk auf einer neuen Instanz verwenden

Wenn Sie immer noch Daten von Ihrem nichtflüchtigen Bootlaufwerk wiederherstellen müssen, können Sie das Bootlaufwerk trennen und als sekundäres Laufwerk an eine neue Instanz anhängen.

  1. Löschen Sie die VM, zu der Sie keine Verbindung herstellen können, und behalten Sie ihr Bootlaufwerk bei:

    gcloud compute instances delete VM_NAME \
   --keep-disks=boot

    Ersetzen Sie VM_NAME durch den Namen der VM, zu der Sie keine Verbindung herstellen können.

  2. Erstellen Sie eine neue VM mit dem Bootlaufwerk der alten VM. Geben Sie den Namen des Bootlaufwerks der soeben gelöschten VM an.

  3. Stellen Sie über SSH eine Verbindung zu Ihrer neuen VM her.

    gcloud compute ssh NEW_VM_NAME

    Ersetzen Sie dabei NEW_VM_NAME durch den Namen der neuen VM.

Prüfen, ob das VM-Bootlaufwerk voll ist

Ihre VM ist möglicherweise nicht mehr zugänglich, wenn das Bootlaufwerk voll ist. Die Fehlerbehebung für dieses Szenario kann schwierig sein, da nicht immer klar ist, ob das Problem mit der VM-Verbindung auf ein volles Bootlaufwerk zurückzuführen ist. Weitere Informationen zu diesem Szenario finden Sie unter Fehlerbehebung bei einer VM, die aufgrund eines vollen Bootlaufwerks nicht zugänglich ist.

Diagnosemethoden für Windows-VMs

SSH-Metadaten zurücksetzen

Wenn Sie über SSH keine Verbindung zu einer Windows-VM herstellen können, versuchen Sie, den Metadatenschlüssel enable-windows-ssh zu deaktivieren und SSH für Windows noch einmal zu aktivieren.

  1. Legen Sie den enable-windows-ssh-Metadatenschlüssel auf FALSE fest. Informationen zum Festlegen von Metadaten finden Sie unter Benutzerdefinierte Metadaten festlegen.

    Warten Sie einige Sekunden, bis die Änderung wirksam wird.

  2. SSH für Windows wieder aktivieren

  3. Stellen Sie noch einmal eine Verbindung zur VM her.

über einen RDP-Client eine Verbindung zur VM herstellen

Wenn Sie die Ursache fehlgeschlagener SSH-Verbindungen zu Ihrer Windows-VM nicht diagnostizieren und beheben können, stellen Sie eine Verbindung über RDP her.

Nachdem Sie eine Verbindung zur VM hergestellt haben, überprüfen Sie die OpenSSH-Logs.

SSH-Probleme mit gcpdiag beheben

gcpdiag ist ein Open-Source-Tool. Es ist kein offiziell unterstütztes Google Cloud-Produkt. Mit dem Tool gcpdiag können Sie Probleme mit Google Cloud-Projekten identifizieren und beheben. Weitere Informationen finden Sie im gcpdiag-Projekt auf GitHub.

In diesem gcpdiag-Runbook werden mögliche Ursachen für Probleme mit SSH-Verbindungen sowohl bei Windows- als auch bei Linux-VMs in Google Cloud untersucht. Dabei werden die folgenden Bereiche geprüft:
  • VM-Zustand:Prüft, ob die VM ausgeführt wird und über ausreichende Ressourcen (CPU, Arbeitsspeicher, Laufwerkspeicher) verfügt.
  • Berechtigungen: Mit dieser Option wird sichergestellt, dass Sie die richtigen IAM-Berechtigungen haben, um SSH-Schlüssel zu konfigurieren.
  • VM-Einstellungen: Verifiziert, dass SSH-Schlüssel und andere Metadaten richtig konfiguriert sind.
  • Netzwerkregeln:Prüft die Firewallregeln, um sicherzustellen, dass SSH-Traffic zulässig ist.
  • Gastbetriebssystem: Sucht nach internen Betriebssystemproblemen, die SSH blockieren könnten.

Google Cloud Console

  1. Führen Sie den folgenden Befehl aus und kopieren Sie ihn. 
    2. gcpdiag runbook gce/ssh \
    --parameter project_id=PROJECT_ID \
    --parameter name=VM_NAME \
    --parameter zone=ZONE \
    --parameter principal=PRINCIPAL \
    --parameter tunnel_through_iap=IAP_ENABLED \
    --parameter check_os_login=OS_LOGIN_ENABLED
    --parameter local_user=LOCAL_USER \
    --parameter check_ssh_in_browser=CHECK_SSH_IN_BROWSER
  2. Öffnen Sie die Google Cloud Console und aktivieren Sie Cloud Shell.
    3. Cloud Console öffnen
  3. Fügen Sie den kopierten Befehl ein.
  4. Führen Sie den Befehl gcpdiag aus, um das Docker-Image gcpdiag herunterzuladen und dann Diagnoseprüfungen durchzuführen. Folgen Sie gegebenenfalls der Anleitung für die Ausgabe, um fehlgeschlagene Prüfungen zu beheben.

Docker

Sie können gcpdiag mit einem Wrapper ausführen, der gcpdiag in einem Docker-Container startet. Docker oder Podman muss installiert sein.

  1. Kopieren Sie den folgenden Befehl und führen Sie ihn auf Ihrer lokalen Workstation aus.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Führen Sie den Befehl gcpdiag aus. 
    ./gcpdiag runbook gce/ssh \
    --parameter project_id=PROJECT_ID \
    --parameter name=VM_NAME \
    --parameter zone=ZONE \
    --parameter principal=PRINCIPAL \
    --parameter tunnel_through_iap=IAP_ENABLED \
    --parameter check_os_login=OS_LOGIN_ENABLED
    --parameter local_user=LOCAL_USER \
    --parameter check_ssh_in_browser=CHECK_SSH_IN_BROWSER

Verfügbare Parameter für dieses Runbook ansehen

Ersetzen Sie Folgendes:

  • PROJECT_ID: Die ID des Projekts, das die Ressource enthält
  • VM_NAME: Der Name der Ziel-VM in Ihrem Projekt.
  • ZONE: Die Zone, in der sich die Ziel-VM befindet.
  • PRINCIPAL: Das Hauptkonto des Nutzers oder Dienstkontos, das die SSH-Verbindung initiiert. Für die schlüsselbasierte Authentifizierung verwenden Sie den von Ihrem Cloud Shell-Befehlszeilentool authentifizierten oder in der Google Cloud Console angemeldeten Nutzer. Beim Identitätswechsel für Dienstkonten sollte dies die E-Mail-Adresse des Dienstkontos sein.
  • IAP_ENABLED: Boolescher Wert (wahr oder falsch), der angibt, ob Identity-Aware Proxy für die Herstellung der SSH-Verbindung verwendet wird. Standard: true
  • OS_LOGIN_ENABLED: Boolescher Wert (wahr oder falsch), der angibt, ob OS Login für die SSH-Authentifizierung verwendet wird. Standard: true
  • LOCAL_USER:Posix-Nutzer auf der VM.
  • CHECK_SSH_IN_BROWSER:Ein boolescher Wert, der prüft, ob SSH im Browser möglich ist.

Nützliche Flags:

Eine Liste und Beschreibung aller gcpdiag-Tool-Flags finden Sie in der gcpdiag-Nutzungsanleitung.

Nächste Schritte