Не удается подключиться по SSH к экземплярам виртуальной машины GCP, которые раньше работали

#google-cloud-platform #google-compute-engine

#google-cloud-platform #google-compute-engine

Вопрос:

Вчера я создал несколько экземпляров виртуальной машины GCP, все с использованием одинаковой конфигурации, но выполняющих разные задачи. Я мог подключиться по SSH к этим экземплярам через консоль GCP, и все они работали нормально.
Сегодня я хочу проверить, выполнены ли задачи, но я больше не могу подключиться по SSH ни к одному из этих экземпляров через браузер…Сообщение об ошибке гласит:

 Connection via Cloud Identity-Aware Proxy Failed
Code: 4010
Reason: destination read failed
You may be able to connect without using the Cloud Identity-Aware Proxy.
  

Итак, я повторил попытку с отключенным прокси-сервером с облачной идентификацией. Но затем он читает:

 Connection Failed
An error occurred while communicating with the SSH server. Check the server and the network configuration.
  

Выполняется

 gcloud compute instances list
  

отображаются все мои экземпляры, и статус RUNNING .
Но когда я запустил

 gcloud compute instances get-serial-port-output [instance-name]
  

используя [instance-name], возвращенный из приведенной выше команды. (Это делается для проверки, не закончилось ли свободное место на загрузочном диске экземпляра.)
Он вернул

 (gcloud.compute.instances.get-serial-port-output) Could not fetch serial port output: The resource '...' was not found
  

Дополнительная информация:
Я получаю доступ к экземпляру виртуальной машины из того же Интернета (моего домашнего Интернета), и все остальное остается тем же
Я владелец проекта
Моя учетная запись использует бесплатную пробную версию GCP с кредитом в размере 300 долларов
Экземпляры имеют тип компьютера c2-standard-4 и используют глубокое обучение Linux
Конфигурация gcloud выглядит правильно для меня:

 $ gcloud config list
[component_manager]
disable_update_check = True
[compute]
gce_metadata_read_timeout_sec = 5
[core]
account = [my_account]
disable_usage_reporting = True
project = [my_project]
[metrics]
environment = devshell
  

Обновить:
Я сбросил один из экземпляров, и теперь я могу успешно подключиться по SSH к этому экземпляру. Однако задание, выполняемое на экземпляре, остановилось после сброса.
Я хочу, чтобы задания выполнялись в других экземплярах. Есть ли способ подключиться по SSH к другим экземплярам без сброса?

Комментарии:

1. Дважды проверьте PROJECT_ID, РЕГИОН и идентификатор, который вы используете. Используйте команды gcloud auth list и gcloud config list . Попробуйте gcloud compute instances list . Чтобы помочь вам получить ответы, не говорите «Несмотря ни на что». Опубликуйте именно то, что вы пробовали, и точное сообщение об ошибке. Утверждения типа «из того же Интернета» не помогают. Если вы не используете статические IP-адреса на своем домашнем шлюзе / маршрутизаторе (маловероятно), возможно, ваша сеть изменилась. Другими словами, будьте конкретны в деталях и не думайте, что мы можем догадаться.

2. Спасибо! Я обновил сообщение

Ответ №1:

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

Вы должны иметь возможность видеть выходные данные на последовательной консоли экземпляра, используя gcloud compute instances get-serial-port-output [instance-name] , но если по какой-то причине вы этого не делаете, вы можете попробовать вместо этого использовать консоль GCP — перейдите к деталям экземпляра и нажмите на последовательный порт 1 (консоль), и вы увидите выходные данные.

Вы даже можете взаимодействовать со своей виртуальной машиной (войти) через консоль. Это особенно полезно, если что-то остановило службу ssh, но для этого вам нужен логин / пароль, поэтому сначала вы должны получить доступ к виртуальной машине или использовать сценарий запуска, чтобы добавить пользователя с вашим паролем. Но опять же — для этого требуется перезапуск.

В любом случае кажется, что перезапуск вашей виртуальной машины — лучший вариант. Но вы можете попытаться выяснить, что вызывает остановку службы ssh через некоторое время, просмотрев журналы. Или вы можете создать свой собственный (дисковое пространство, память, процессор и т.д.) С помощью cron with df -Th /mountpoint/path | tail -n1 >> /name_of_the_log_file.log .

Вы можете, например, использовать cron для проверки и запуска службы ssh.

И если что-то работает не так, как предполагалось (согласно документации) — перейдите в IssueTracker и создайте новую проблему, чтобы получить дополнительную помощь.

Комментарии:

1. Спасибо @Wojtek_B. Перезапуск экземпляра виртуальной машины — это все, что потребовалось! БАЦ, прямо в (через консоль).