Fehlerbehebung für SSH

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

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.

Berechtigung verweigert

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.

    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.

    Führen Sie einen der folgenden Schritte aus, 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
      

      Dabei gilt:
      • 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 mit der Google Cloud Console oder dem gcloud-Befehlszeilentool eine Verbindung zur 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.
  • Der sshd-Daemon wird nicht ausgeführt oder ist nicht ordnungsgemäß konfiguriert. Der sshd-Daemon aktiviert SSH-Verbindungen. Ist er falsch konfiguriert oder wird nicht ausgeführt, können Sie keine Verbindung zur VM herstellen.

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

Verbindungsfehler

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

  • Cloud Console

    Connection Failed
    
    We are unable to connect to the VM on port 22.
    
  • Das gcloud-Tool:

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

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.

  • Die Firewallregel, die SSH zulässt, fehlt oder ist falsch konfiguriert. Standardmäßig erlauben Compute Engine-VMs den SSH-Zugriff auf Port 22. Wenn die Regel default-allow-ssh fehlt oder falsch konfiguriert ist, können Sie keine Verbindung zu VMs herstellen.

    Lösung: Prüfen Sie Ihre Firewallregeln und fügen Sie default-allow-ssh neu hinzu oder konfigurieren Sie es neu.

  • 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.

  • Ihre benutzerdefinierte SSH-Firewallregel lässt keinen Traffic von Google-Diensten zu. SSH-Verbindungen von der Cloud Console werden abgelehnt, wenn benutzerdefinierte Firewallregeln keine Verbindungen aus dem IP-Adressbereich von Google zulassen.

    So beheben Sie das Problem:

    1. Tragen Sie die IP-Adressbereiche von Google mit dem folgenden Befehl zusammen:

      dig +qr +short txt `dig +short TXT _spf.google.com | grep -oE 'include:\S*' | cut -d':' -f2 | xargs` | grep -oE 'ip[46]:\S*' | sort | uniq
      
    2. Aktualisieren Sie Ihre benutzerdefinierte Firewallregel, um Traffic von Google-IP-Adressen zuzulassen. Weitere Informationen finden Sie unter Firewallregeln aktualisieren.

  • Der sshd-Daemon wird nicht ausgeführt oder ist nicht ordnungsgemäß konfiguriert. Der sshd-Daemon aktiviert SSH-Verbindungen. Ist er falsch konfiguriert oder wird nicht ausgeführt, können Sie keine Verbindung zur VM herstellen.

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

Verbindung zum Back-End konnte nicht hergestellt werden

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

  • Cloud Console

    -- Connection via Cloud Identity-Aware Proxy Failed
    
    -- Code: 4003
    
    -- Reason: failed to connect to backend
    
  • Das gcloud-Tool:

    ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: u'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.

Fehlerhafte 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:

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

Wenn Sie feststellen möchten, ob die Netzwerkverbindung funktioniert, stellen Sie mit dem nmap-Tool eine Verbindung zu Ihrer Instanz an Port 22 her. Falls nach dem Herstellen einer Verbindung 22/tcp open ssh angezeigt wird, ist Ihre Netzwerkverbindung aktiv. Damit sind Firewallprobleme ausgeschlossen.

  1. Rufen Sie mit dem gcloud-Tool den externen natIP-Wert für Ihre Instanz auf:

    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 Instanz.

    Führen Sie den Befehl nmap aus, um die Netzwerkverbindung zu Ihrer Instanz zu testen. Ersetzen Sie dabei external-ip durch die externe IP-Adresse, die Sie in Schritt 1 ermittelt haben:

    nmap external-ip
    

    Wenn die Instanz beispielsweise die externe IP-Adresse 198.51.100.1 hat, führen Sie den folgenden Befehl aus:

    nmap 198.51.100.1
    Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-18 16:04 Greenwich Standard Time
    Nmap scan report for 229.30.196.35.bc.googleusercontent.com (198.51.100.1)
    Host is up (0.0061s latency).
    Not shown: 998 filtered ports
    PORT     STATE  SERVICE
    22/tcp   open   ssh
    Nmap done: 1 IP address (1 host up) scanned in 6.22 seconds
    

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 dem gcloud-Tool als ein anderer Nutzer an. Ersetzen Sie dabei in der SSH-Anfrage ANOTHER_USERNAME durch einen anderen Nutzernamen. Das gcloud-Tool 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 mithilfe der seriellen Konsole beheben

Wir empfehlen Ihnen, die Logs der seriellen Konsole auf Verbindungsfehler zu prüfen. Von Ihrer lokalen Workstation aus können Sie mit einem Browser auf die serielle Konsole zugreifen.

Aktivieren Sie den Lese-/Schreibzugriff auf die serielle Konsole einer Instanz, damit Sie sich bei der Konsole anmelden und Probleme mit der Instanz beheben können. Dies ist nützlich, 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.

Wie Sie interaktiven Zugriff aktivieren und eine Verbindung zur seriellen Konsole einer Instanz herstellen, erfahren Sie unter Mit der seriellen Konsole interagieren.

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 den Anweisungen zum Herstellen einer Verbindung zu einer Instanz ohne externe IP-Adresse.

  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.

Das Skript compute-ssh-diagnostic ist ein guter Ausgangspunkt für die Erfassung von Diagnoseinformationen bei den häufigsten Problemen.

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 alten VM-Bootlaufwerk:

    gcloud compute instances create NEW_VM_NAME \
       --disk name=BOOT_DISK_NAME,boot=yes,auto-delete=no 

    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.
  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.

Nächste Schritte