#ssh #google-cloud-platform
#ssh #google-cloud-platform
Вопрос:
Я не могу подключиться к своему экземпляру виртуальной машины. Правило «по умолчанию-разрешить-ssh» в брандмауэре — «Разрешить». Я думаю, может быть, журналы помогают:
Aug 30 09:23:24 my-vm google-accounts: ERROR Exception calling the response handler. [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/'].#012Traceback (most recent call last):#012 File "/usr/lib/python3/dist-packages/google_compute_engine/metadata_watcher.py", line 200, in WatchMetadata#012 handler(response)#012 File "/usr/lib/python3/dist-packages/google_compute_engine/accounts/accounts_daemon.py", line 285, in HandleAccounts#012 self.utils.SetConfiguredUsers(desired_users.keys())#012 File "/usr/lib/python3/dist-packages/google_compute_engine/accounts/accounts_utils.py", line 318, in SetConfiguredUsers#012 mode='w', prefix=prefix, delete=True) as updated_users:#012 File "/usr/lib/python3.6/tempfile.py", line 681, in NamedTemporaryFile#012 prefix, suffix, dir, output_type = _sanitize_params(prefix, suffix, dir)#012 File "/usr/lib/python3.6/tempfile.py", line 269, in _sanitize_params#012 dir = gettempdir()#012 File "/usr/lib/python3.6/tempfile.py", line 437, in gettempdir#012 tempdir = _get_default_tempdir()#012 File "/usr/lib/python3.6/tempfile.py", line 372, in _get_default_tempdir#012 dirlist)#012FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']
Aug 30 09:23:30 my-vm systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
Aug 30 09:23:30 my-vm systemd[1]: snapd.service: Killing process 15472 (snapd) with signal SIGKILL.
Aug 30 09:23:30 my-vm systemd[1]: snapd.service: Main process exited, code=killed, status=9/KILL
Aug 30 09:23:30 my-vm systemd[1]: snapd.service: Failed with result 'timeout'.
Aug 30 09:23:30 my-vm systemd[1]: Failed to start Snap Daemon.
Aug 30 09:23:31 my-vm systemd[1]: snapd.service: Service hold-off time over, scheduling restart.
Aug 30 09:23:31 my-vm systemd[1]: snapd.service: Scheduled restart job, restart counter is at 939.
Aug 30 09:23:31 my-vm systemd[1]: Stopped Snap Daemon.
Aug 30 09:23:31 my-vm systemd[1]: Starting Snap Daemon...
Aug 30 09:23:31 my-vm snapd[15582]: AppArmor status: apparmor is enabled and all features are available
Aug 30 09:23:31 my-vm snapd[15582]: AppArmor status: apparmor is enabled and all features are available
Ответ №1:
В основном это происходит из-за того, что ваше дисковое хранилище заполнено. Если у вас есть другой тип доступа к вашей виртуальной машине, такой как подключение с помощью последовательной консоли, проверьте статус выделенного дискового пространства через него и попробуйте освободить немного места или добавить дополнительное хранилище данных, если оно заполнено.
Комментарии:
1. Я не могу подключиться к своей виртуальной машине через SSH (в панели Google и с моего ПК Putty), и я не знаю другого типа доступа. Я добавляю дисковое пространство в свое хранилище, но проблема не решается
2. Вам необходимо подключиться с помощью последовательной консоли. проверьте эту ссылку cloud.google.com/compute/docs/instances /…
3. Я думаю, что @Afshin указал правильное направление, просто хочу добавить здесь, что этот документ может быть полезен в этой проблеме, особенно проверьте экземпляр виртуальной машины, не выключая его , и используйте свой диск в новом экземпляре
4. Спасибо за эту статью. Когда я подключаю nmap к своему ip, я вижу это: я здесь @cloudshell: ~ (onyx-cosmos-266419) $ nmap .* .**.** Запускаю Nmap 7.70 ( nmap.org ) в 2020-08-31 18:11 UTC Примечание: хост, похоже, не работает. Если это действительно работает, но блокирует наши проверки ping, попробуйте -Pn Моя виртуальная машина заблокировала любое подключение, верно?
5. Нет проблем @МаксимСкладаний Если у вас есть брандмауэр для экземпляра, который открыт для входа в порт ssh, обычно tcp порт 22, подключение здесь не должно быть проблемой. Вы можете проверить или перечислить брандмауэр для экземпляра, следуя документу .