ОШИБКА: (gcloud.compute.ssh) [/usr/bin/ssh] завершена с кодом возврата [255]
После нескольких секунд простоя меня выгоняли из моего экземпляра вычислительного движка с указанной ошибкой (255). Я использовал gcloud compute ssh для входа в систему. Я использую настройку брандмауэра по умолчанию, которая, я считаю, будет достаточно для ssh. Но если я что-то упустил, пожалуйста, укажите и предложите исправление этой ошибки. По сути, я не могу выполнить какую-либо эффективную работу на этом этапе, так как мне приходится много раз использовать ssh.
Заранее спасибо.
Anh-
26 ответов
gcloud запрещает соединение ssh, если в настройке произошли изменения, например, после изменения зоны или региона по умолчанию или создания другого экземпляра. Затем вы должны обновить ключи ssh в ваших метаданных с помощью
sudo gcloud compute config-ssh
Если из-за этого возникают жалобы на разные записи в вашем конфигурационном файле, где хранятся записи ключей ssh, ~/.ssh/config удалите этот файл и снова выполните приведенную выше команду.
255 - интерактивный код выхода ssh для сбоя ssh - в противном случае интерактивный ssh завершается с кодом выхода последней команды, выполненной в сеансе ssh.
В следующий раз, когда вы получите код выхода 255 из ssh, попробуйте запустить с --ssh-flag="-vvv" (more v's => more отладочный вывод) и посмотреть, поможет ли это отследить проблемы с соединением.
Для тех, кто заходит на эту страницу. Это помогло мне решить проблему. Попробуйте следующее:
- Зайдите в ваш гугл и удалите ключ SSH для сервера
- Запустите команду gcloud снова
Кажется, это особенность / проблема самой Google Cloud Platform, мы собираемся продолжить ее проверку.
Если сеть по умолчанию была отредактирована или не использует сеть по умолчанию, вам может понадобиться явно включить ssh-доступ, добавив правило межсетевого экрана:
$ gcloud compute firewall-rules create --network=YOUR_NETWORK \
default-allow-ssh --allow tcp:22
После этого повторите команду "gcloud compute ssh".
Это реальная проблема с очень небольшим количеством документации, чтобы иметь дело с этим.
Через некоторое время после создания экземпляра с использованием фрагмента gshoud sdk ssh, предоставленного через консоль GCP, перестала работать и постоянно возникала ошибка, при которой 255 делает подключение к ssh в экземпляре доступным только через браузер через консоль GCP для рассматриваемого экземпляра вычислений. Не говоря уже о том, что это случалось со мной во многих различных случаях, некоторые из которых не затрагивали разрешения учетной записи по умолчанию после первоначальной настройки и развертывания, что слишком расстраивает. Потому что без причины он просто перестает работать... работает, а потом не...
Единственное, что сработало для меня, - это создание нового пользователя для связи через gcloud sdk! Будь то Windows/PowerShell или Linux локально, используя следующий фрагмент:
gcloud compute ssh newuser-name @ instance-name
Это все в соответствии с документацией GCP здесь: https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-ssh
Все остальное пропущено в соответствии с предложениями в документации - порт 22 открыт с доступом, что означает, что это должно быть проблемой для пользователей по умолчанию authorization_keys, КОТОРЫЕ они не предоставляют абсолютно никакой документации о том, как это исправить - по крайней мере, ничего, что я мог бы найти при исправлении (не создавая или удаляя)
Я попытался обновить учетную запись, попытался удалить пользователя и учетные данные из экземпляра, похоже, ничего не работает. с помощью:
gcloud compute --project "имя-проекта" ssh --zone "us-east4-a" "имя-экземпляра"
Просто не работает... - даже попробовал 'gcloud compute config-ssh --force-key-file-overwrite' НИЧЕГО НЕ РАБОТАЕТ...
Но создание нового пользователя работает каждый раз, и как только пользователь создан, вы можете продолжать использовать этого пользователя через gcloud sdk
Это обходной путь, и я ненавижу обходной путь для таких вещей, но для моего здравомыслия это работает по крайней мере до тех пор, пока я не смогу выяснить, как сбросить разрешения учетной записи по умолчанию, поэтому, если у кого-то есть какие-либо идеи или они могут указать мне направление для что я более чем ценю это!
Если у вас включен прокси-сервер с идентификацией (IAP), попробуйте добавить --tunnel-through-iap вариант для gcloud compute ssh команда.
$ gcloud compute ssh --zone <zone> --project <project> --tunnel-through-iap <instance-name>
Я ошибся, заявив, что брандмауэр по умолчанию разрешает все подключения в одном экземпляре. Обратное оказалось правдой. Пожалуйста, обратитесь к соответствующему правилу брандмауэра должно быть установлено, чтобы разрешить подключение к экземпляру
Anh-
Я знаю, что это было открыто давно, но для более свежего обновления по этой теме. У меня была такая же проблема с подключением по ssh. Он выдавал код ошибки 225. Очевидно, возникла проблема с подключением. В разделе Сеть VPC-> Брандмауэр уже было задано правило брандмауэра, разрешающее ssh. Однако, чтобы решить эту проблему, мне пришлось перейти в конкретную сеть и создать правило в соответствии с правилами сетевого брандмауэра. Сведения о сети VPC -> ПРАВИЛА БРАНДВОУЛА и создайте правило TCP для входящего трафика для порта 22.
Дополнительная информация для людей, попадающих на эту страницу, если вы используете вытесняемые экземпляры, чтобы сэкономить некоторые вычислительные затраты, это также может быть причиной того, что вас так выгнали. Возможно, ваш экземпляр остановился случайно.
В моем случае я создал загрузочный диск для виртуальной машины без добавления информации о том, какой исходный образ он должен иметь. Из-за этого, несмотря на то, что экземпляр работал нормально и действовало правило ssh-allow, виртуальная машина не загружалась.
Наконец, я добавил исходный образ на диск и смог подключиться к виртуальной машине по ssh.
Надеюсь, это кому-то поможет.
У меня была такая же ошибка. Я перезапустил экземпляр виртуальной машины, и ssh работает нормально
У меня была проблема, когда после нажатия кнопки SSH он продолжал пытаться установить соединение и терпел неудачу. После долгой борьбы я решил это, добавив себе роль пользователя учетной записи службы. Если ваша учетная запись была создана после создания экземпляра виртуальной машины, это может привести к такой ситуации.
Если у вас возникла проблема с удаленным доступом к экземпляру виртуальной машины g-cloud с терминала вашего компьютера, и вы получаете код ошибки 255, проблема в том, что протоколы ssh на вашем компьютере неверны или не обновлены.
В этом случае лучший способ исправить это — перейти в свой домашний каталог (на вашем компьютере), проверить скрытые файлы и найти папку « .ssh ». Просто удалите эту папку и снова откройте терминал bash. Затем снова запустите команду gcloud vm.
Пример:you@your_computer:~$ gcloud beta calculate ssh --zone "us-central1-a" " your_VM_name " --project " your_project_name "
На этот раз вы должны вместо получения кода ошибки 255, сообщения ниже: ПРЕДУПРЕЖДЕНИЕ: файл закрытого ключа SSH для gcloud не существует. ПРЕДУПРЕЖДЕНИЕ. Файл открытого ключа SSH для gcloud не существует. ВНИМАНИЕ: у вас нет ключа SSH для gcloud. ВНИМАНИЕ: Генерация ключей SSH будет выполнена для генерации ключа. Этому инструменту необходимо создать каталог [ /home/ваше_имя/.ssh ], прежде чем он сможет генерировать ключи SSH.
Вы хотите продолжить (Т/Н)?
Введите «Y», и gcloud настроит новые протоколы, создав новый обновленный файл .ssh . После этого вы сможете без проблем получить доступ к своей виртуальной машине с помощью команды gcloud.
Это должно решить проблему Ура https://blackpearlmatrix.com
Я получал тот же код ошибки, когда пытался войти в ssh.
Я попытался воссоздать ключ ssh, как упомянуто в этом ответе; Однако это не помогло.
Что работает это:
- Запустите экземпляр виртуальной машины из облачной консоли Google в браузере через Compute Engine -> Экземпляры виртуальной машины, а затем
- выберите экземпляр, установив флажок и нажав кнопку запуска
или же
- щелкнув по имени экземпляра, вы попадете на страницу экземпляра, где вы нажмете кнопку запуска.
После успешного запуска экземпляра вы можете войти в него через терминал.
Я проверил это, попробовав это два раза.
У меня была такая же проблема.
Я подключил последовательное управление и проверил логи. и был журнал ошибок типа " нет места на диске ". Затем я изменил размер диска, как написано в этом документе.
Теперь я могу подключиться к экземпляру с помощью ssh.
В конце концов мне пришлось удалить свой экземпляр и сделать новый с тем же диском. Для получения подробной информации см. https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-ssh ошибок / устранение неполадок- ssh# use_your_disk_on_a_new_instance.
У меня были точно такие же симптомы - в моем случае причина заключалась в следующем. Я использовал root user + ключ ssh, тогда как вход в систему по умолчанию отключен в /etc/ssh/sshd_config (свойство PermitRootLogin).
Возможно, у вас есть правило, которое разрешает только включенным IP-адресам передавать ssh в виртуальную машину gcloud. Возможно, вы забыли включить рабочий VPN или IP-адрес рабочего офиса.
Что сработало для меня, так это включение моего брандмауэра. (На Mac ssh-соединение с экземпляром gcp).
В другом случае ошибки мое соединение работало нормально, когда я был в сети, но не когда я был в Wi-Fi. Переключение обратно на Ethernet позволило мне снова подключиться.
Попробуйте перезагрузить компьютер.
Я получил ту же ошибку и попробовал gcloud config ssh, как упоминалось ранее, безрезультатно. Затем я проверил, есть ли у идентификаторов и ролей serviceaccount и разработчика права «редактора», и это нормально. Я запустил новый экземпляр и вышел из всех своих других учетных записей Google, но он все равно вызывал ошибку. Затем я перезапустил свой компьютер и больше не входил в другие учетные записи Google. Это исправило это.
При использовании IAP GCP сохраняет ключ в метаданных экземпляра, а затем передает его в файл.
Вы можете получить ошибку, о которой говорит OP, когда вы удаляете ключ из файла, и он все еще находится в метаданных экземпляра. Причина:
- GCP проверяет, что пользовательская комбинация клавиш, которую вы используете для ssh, уже есть в метаданных экземпляра.
- Предполагается, что существует в файле для этого пользователя и не распространяется ключ.
- Поскольку ключа нет в
~/.ssh/authorized_keysфайл по какой-либо причине (вы удалили его, кто-то удалил его и т. д. и т. д.) - вам отказано в доступе.
Если это так, то исправить просто: удалите запись метаданных экземпляра для этого пользователя, комбинацию клавиш (прикрепили изображение для ссылки, просто нажмите
X и удалите свой неисправный ключ) и попробуйте снова ssh
Повторная инициализация gcloud с помощью "gcloud init" и создание новых ключей ssh решили для меня проблему.
В моем случае проблема решилась после перезапуска виртуальной машины. если вы можете получить доступ к виртуальной машине ранее и внезапно возникают проблемы с SSH, попробуйте перезапустить ее.
Разрешение проверьте, есть ли у вас туннельный пользователь, защищенный IAP.
gcloud compute ssh --zone "your_zone" "instance_name" --tunnel-through-iap --project "project_name"
Если это не работает, проверьте встроенный SSH-клиент GCP и нажмите «Открыть» в окне браузера.
Надеюсь, это поможет!!!
Попробуйте переключиться на другое подключение к Интернету
Итак, я получал ту же ошибку, но в моем случае я вообще не смог войти в экземпляр.
(base) girish@girish:~$ gcloud beta compute ssh --zone "asia-east1-b" "fp-1" --project "fp-public"
ssh: connect to host 12.345.678.90 port 22: Resource temporarily unavailable
ERROR: (gcloud.beta.compute.ssh) [/usr/bin/ssh] exited with return code [255].
(base) girish@girish:~$ gcloud beta compute ssh --ssh-flag='-vvv' --zone "asia-east1-b" "fp-1" --project "fp-public"
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "12.345.678.90" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 12.345.678.90 [12.345.678.90] port 22.
[debug1: connect to address 12.345.678.90 port 22: Resource temporarily unavailable
ssh: connect to host 12.345.678.903 port 22: Resource temporarily unavailable
ERROR: (gcloud.beta.compute.ssh) [/usr/bin/ssh] exited with return code [255].
Что сработало для меня: я попытался переустановить множество вещей и повторно инициализировать различные конфигурации, а затем попал в поток, который предлагает изменить используемую вами Интернет-сеть, и это сработало!!
Что касается меня, то другие мои товарищи по команде смогли войти в машину, но не я. Поэтому я попросил их создать пользователя с моим именем и правами sudo, вошел в последовательную консоль и изменилpasswordAuthentication к yes с последующим sudo service ssh restart (для некоторых это могло быть sudo service sshd restart.)
Опубликуйте это Я смог войти с помощью
ssh -o PreferredAuthentications=password username@publicIP -p 22
У меня этот трюк сработал.
Может быть, это кому-то поможет. Я столкнулся с этой проблемой, когда был за брандмауэром моей работы. Как только я подключился к общедоступному Wi-Fi, все работало отлично.