Ich habe einen Ubuntu-Server auf Google Cloud/Compute Engine, der problemlos funktioniert. Ich kann mich per SSH über die Befehlszeile oder über die Google Cloud-Dashboard-Konsole darauf anmelden.
Wenn ich einen Snapshot davon erstelle, um den Server zu klonen, kann ich mich nicht per SSH mit dem neuen Klon verbinden. Der SSH-Daemon scheint nicht zuzuhören. Ich kann mich nicht einmal über das Google Cloud-Dashboard per SSH mit ihm verbinden.
Weiß jemand warum?
Von der seriellen Konsole aus (Hinweis: Ich habe SHA256 im Einfügen bearbeitet):
Mar 20 20:16:19 qa-for-work cloud-init[1042]: Generating public/private ed25519 key pair.
Mar 20 20:16:19 qa-for-work cloud-init[1042]: Your identification has been saved in /etc/ssh/ssh_host_ed25519_key.
cloud-init[1042]: Your identification has been saved in /etc/ssh/ssh_host_ed25519_key.
Mar 20 20:16:20 qa-for-work cloud-init[1042]: Your public key has been saved in /etc/ssh/ssh_host_ed25519_key.pub.
[ 110.667373] cloud-init[1042]: Your public key has been saved in /etc/ssh/ssh_host_ed25519_key.pub.
Mar 20 20:16:20 qa-for-work cloud-init[1042]: The key fingerprint is:
[ 110.667475] cloud-init[1042]: The key fingerprint is:
Mar 20 20:16:20 qa-for-work cloud-init[1042]: SHA256:u6ros 4MQtfpO5GM root@qa-for-work
[ 110.667560] cloud-init[1042]: SHA256:u6ros 1GtaVy4MQtfpO5GM root@qa-for-work
Mar 20 20:16:20 qa-for-work cloud-init[1042]: The key's randomart image is:
[ 110.667644] cloud-init[1042]: The key's randomart image is:
Mar 20 20:16:20 qa-for-work cloud-init[1042]: +--[ED25519 256]--+
[ 110.667775] cloud-init[1042]: +--[ED25519 256]--+
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | o*o..=+o... |
[ 110.667864] cloud-init[1042]: | o*o..=+o... |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | o.o.o.+... |
[ 110.667939] cloud-init[1042]: | o.o.o.+... |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | o . ...o . |
[ 110.668037] cloud-init[1042]: | o . ...o . |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | = . .. + |
[ 110.668116] cloud-init[1042]: | = . .. + |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | + = o S . |
[ 110.668192] cloud-init[1042]: | + = o S . |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | o + o + . |
[ 110.668275] cloud-init[1042]: | o + o + . |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: |o + o E |
[ 110.668349] cloud-init[1042]: |o + o E |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: |.*.+ . + o |
[ 110.668503] cloud-init[1042]: |.*.+ . + o |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: |ooB+o...o |
[ 110.668596] cloud-init[1042]: |ooB+o...o |
Mar 20 20:16:20 qa-for-work systemd[1]: Started Initial cloud-init job (metadata service crawler).
Mar 20 20:16:20 qa-for-work cloud-init[1042]: +----[SHA256]-----+
[ 110.668946] cloud-init[1042]: +----[SHA256]-----+
Mar 20 20:16:20 qa-for-work ntpdate[1023]: adjust time server 169.254.169.254 offset 0.361638 sec
Mar 20 20:16:20 qa-for-work systemd[1]: Reached target Network is Online.
Mar 20 20:16:20 qa-for-work systemd[1]: Reached target Cloud-config availability.
Mar 20 20:16:20 qa-for-work systemd[1]: Startup finished in 7.356s (kernel) + 1min 42.350s (userspace) = 1min 49.706s.
Antwort1
Das Problem bestand darin, dass ich an die ursprüngliche Instanz eine angeschlossene Festplatte hatte.
Die Lösung bestand darin, die Einbindung der angeschlossenen Festplatte in auszukommentieren /etc/fstab.
Ein normales Linux-System würde weiterhin booten und SSH ausführen, wenn kein Nicht-Root-Mount-Punkt gemountet wäre. Auch in der seriellen Konsole gab es keine Fehlermeldungen, die darauf hinwiesen.
Obwohl die Google-Cloud immer noch meine Lieblings-Cloud ist, handelt es sich hier um einen großen Fehler ihrerseits.
Antwort2
Wenn die neue Instanz aus einem Snapshot der Quellinstanz erstellt wird, sollte die SSHD-Konfiguration auf der aus dem Snapshot generierten neuen Instanz nicht anders sein als die der Quellinstanz.
Welche Fehlermeldung erhalten Sie, wenn Sie versuchen, per SSH von der Cloud Shell aus zu kommunizieren?
$ gcloud compute ssh INSTANCE_NAME
Wenn Sie einen Snapshot erstellen, handelt es sich dabei um einen Snapshot der Festplatte und er enthält keine Informationen zu anderen Aspekten der Quellmaschine.
Ist es möglich, dass der neuen Instanz, die Sie aus dem Snapshot erstellen, nicht dieselben Netzwerk-Tags zugewiesen wurden wie der Quellinstanz (was möglicherweise den Zugriff auf die neue Instanz über Port 22 verhindert)? Ich denke, das ist definitiv eine Überprüfung wert.
Stellen Sie außerdem sicher, dass Sie der neuen Maschine eine externe IP-Adresse zugewiesen haben.
BEARBEITEN:
Ich habe einige zusätzliche Informationen in Bezug auf die aktualisierten Informationen des Posters bezüglich eines ungültigen fstab-Eintrags hinzugefügt, der den Bootvorgang der Instanz beeinträchtigt (und somit den SSH-Zugriff auf die Instanz beeinflusst).
Es gibt einige nützliche InformationenHierzum Hinzufügen von [NOFAIL_OPTION] zum fstab-Eintrag. Dabei handelt es sich um eine Variable, die angibt, was das Betriebssystem tun soll, wenn es die persistente Festplatte beim Booten nicht mounten kann. Dies kann verwendet werden, um Boot-Probleme im Zusammenhang mit ungültigen fstab-Einträgen zu verhindern.