Compute Engine — экземпляр из снимка не имеет ssh

Compute Engine — экземпляр из снимка не имеет ssh

У меня есть сервер Ubuntu на Google Cloud/Compute Engine, который работает без проблем. Я могу подключиться к нему по ssh из командной строки или через консоль панели инструментов Google Cloud.

Когда я делаю снимок, чтобы клонировать сервер, я не могу подключиться по ssh к новому клону. Демон ssh, похоже, не слушает. Я даже не могу подключиться по ssh из панели управления Google Cloud.

Кто-нибудь знает почему?

Из последовательной консоли (Примечание: я отредактировал sha256 в файле paste):

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.

решение1

Проблема была в том, что у меня был подключен диск к исходному экземпляру.

Решением было закомментировать монтирование подключенного диска в /etc/fstab.

Обычная система Linux продолжит загрузку и запустит ssh, если не будет смонтирована некорневая точка монтирования. Никаких сообщений об ошибках в последовательной консоли не указывало на этот ether.

Хотя облако Google по-прежнему остается моим фаворитом среди облачных решений, это серьезный провал с их стороны.

решение2

Если новый экземпляр создается из снимка исходного экземпляра, конфигурация sshd на новом экземпляре, созданном из снимка, не должна отличаться от конфигурации исходного экземпляра.

Какое сообщение об ошибке вы получаете при попытке подключиться по SSH из Cloud Shell?

$ gcloud compute ssh INSTANCE_NAME

Когда вы делаете снимок, это снимок диска, и он не содержит никакой информации о других аспектах исходной машины.

Возможно ли, что новому экземпляру, который вы создаете из снимка, не были назначены те же сетевые теги, что и исходному экземпляру (что может помешать доступу к порту 22 к новому экземпляру)? Я думаю, это определенно стоит проверить.

Также убедитесь, что вы назначили новому компьютеру внешний IP-адрес.

РЕДАКТИРОВАТЬ:

Я добавил некоторую дополнительную информацию в связи с обновленной информацией автора сообщения о недопустимой записи fstab, влияющей на загрузку экземпляра (и, таким образом, на доступ SSH к экземпляру).

Есть некоторая полезная информацияздесьотносительно добавления [NOFAIL_OPTION] в запись fstab, которая является переменной, указывающей, что должна делать операционная система, если она не может смонтировать постоянный диск во время загрузки. Это можно использовать для предотвращения проблем с загрузкой, связанных с недействительными записями fstab.

Связанный контент