Разрешение отклонено (publickey, gssapi-keyex, gssapi-with-mic)

Ответ 1

Отказано в разрешении, вероятно, указывает на то, что аутентификация закрытого ключа SSH не удалась. Предполагая, что вы используете изображение, полученное из изображений Debian или Centos, рекомендованных gcutil, вероятно, одно из следующих:

• У вас нет ключей ssh, загруженных в ваш keychain ssh, и вы не указали закрытый ключ ssh с опцией -i.
• Ни один из ваших ssh-ключей не соответствует записям в .ssh/authorized_keys для учетной записи, к которой вы пытаетесь войти.
• Вы пытаетесь войти в учетную запись, которая не существует на компьютере, или пытаетесь войти в систему с правами администратора. (Изображения по умолчанию отключают прямой вход в корневой каталог - большинство атак с грубой силой ssh ​​относятся к корневым или другим известным учетным записям со слабыми паролями.)

Как определить, какие учетные записи и ключи находятся в экземпляре:

Там script, который запускается каждую минуту на стандартных изображениях Compute Engine Centos и Debian, которые извлекают запись метаданных 'sshKeys' с сервера метаданных и при необходимости создают учетные записи (с доступом к sudoers). Этот script ожидает записи формы "account:\n" в метаданных sshKeys и может поместить несколько записей в authorized_keys для одной учетной записи. (или при необходимости создать несколько учетных записей)

В последних версиях изображения этот script отправляет свой вывод в последовательный порт через syslog, а также в локальные журналы на машине. Вы можете прочитать последний 1 МБ вывода последовательного порта через gcutil getserialportoutput, что может быть удобно, когда машина не отвечает через SSH.

Как работает gcutil ssh:

gcutil ssh выполняет следующие действия:

• Ищет ключ в $HOME/.ssh/google_compute_engine и вызывает ssh-keygen, чтобы создать его, если он отсутствует.
• Проверяет текущее содержимое записи метаданных проекта для sshKeys для записи, которая выглядит как ${USER}:$(cat $HOME/.ssh/google_compute_engine.pub)
• Если такой записи не существует, добавляется эта запись в метаданные проекта и доходит до 5 минут для распространения метаданных для распространения, а для script внутри виртуальной машины - для замещения новой записи и создания новой учетной записи.
• После того, как новая запись находится на месте (или сразу же, если уже был ключ пользователя: gcutil ssh вызывает ssh несколько аргументов командной строки для подключения к виртуальной машине.

Несколько способов это может сломаться и что вы можете сделать, чтобы исправить их:

• Если вы удалили или модифицировали скрипты, которые читали sshKeys, консоль и инструмент командной строки не поймут, что изменение sshKeys не работает, и большая часть автоматического магии выше может сломаться.
• Если вы пытаетесь использовать raw ssh, он может не найти ваш ключ .ssh/google_compute_engine. Вы можете исправить это с помощью gcutil ssh или путем копирования открытого ключа ssh (заканчивается на .pub) и добавления в запись sshKeys для проекта или экземпляра в консоли. (Вам также нужно будет ввести имя пользователя, возможно, такое же, как имя вашей локальной машины.)
• Если вы никогда не использовали gcutil ssh, у вас, вероятно, нет файла .ssh/google_compute_engine.pub. Вы можете использовать ssh-keygen для создания новой общедоступной/частной ключевой пары SSH и добавить ее в sshKeys, как указано выше, или использовать gcutil ssh для их создания и управления sshKeys.
• Если вы в основном используете консоль, возможно, что имя учетной записи в записи sshKeys не соответствует вашему локальному имени пользователя, вам может потребоваться аргумент -l для SSH.

Ответ 2

Убедитесь, что для разрешений в домашнем каталоге и в домашнем каталоге пользователя на подключаемом хосте установлено значение 700 (владелец пользователя rwx только для того, чтобы другие не увидели подкаталог .ssh).

Затем убедитесь, что каталог ~/.ssh также равен 700 (пользовательский rwx) и что authorized_keys - 600 (пользователь rw).

Частные ключи в каталоге ~/.ssh должны быть 600 или 400 (пользователь rw или пользователь r)

Ответ 3

У меня была такая же проблема, и по какой-то причине sshKeys не синхронизировался с моим пользователем в экземпляре.

Я создал другого пользователя, добавив - ssh_user = anotheruser в команду gcutil.

gcutil выглядел так:

gcutil --service_version="v1" --project="project"  --ssh_user=anotheruser ssh  --zone="us-central1-a" "inst1"

Ответ 4

Я долгое время сталкивался с этой проблемой. Наконец, это была проблема ssh-add. Git Учетные данные ssh не принимались во внимание.

Для вас может работать следующая команда:

ssh-add

Ответ 5

Я просто испытал подобное сообщение [мое было "Permission denied (publickey)" ] после подключения к вычислительной машине VM, которую я только что создал. Прочитав этот пост, я решил попробовать еще раз.

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

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

Я подозреваю, что последнее маловероятно:)

Ответ 6

Я нашел эту ошибку при подключении экземпляра ec2 с помощью ssh. и он появляется, если я пишу неправильное имя пользователя.

например. для ubuntu Мне нужно использовать ubuntu как имя пользователя   и для других мне нужно использовать ec2-пользователя.

Ответ 7

Вы не приняли ответ, так что вот что сработало для меня в PuTTY:

Без изменения имени пользователя я получил этот вопрос как ошибку на шлюзовой машине.

Ответ 8

Вам необходимо следовать этим инструкциям https://cloud.google.com/compute/docs/instances/connecting-to-instance#generatesshkeypair

Если получится "Permission denied (publickey)". с последующей командой ssh -i ~/.ssh/my-ssh-key [USERNAME]@[IP_ADDRESS] вам необходимо изменить файл /etc/ssh/sshd _config и добавить строку AllowUsers [USERNAME]

Затем перезапустите службу ssh с помощью

service ssh restart

если вы получите сообщение "Не удалось загрузить ключ хоста:/etc/ssh/ssh_host_ed25519_key" выполнить: ssh-keygen -A

и, наконец, снова перезапустите службу ssh.

service ssh restart

Ответ 9

Я следил за всем: https://cloud.google.com/compute/docs/instances/connecting-to-instance#generatesshkeypair

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

Решение: Проверьте, имеет ли ваш ключ ssh новую строку. Когда я скопировал свой открытый ключ с помощью cat, он добавил строки в ключ, тем самым сломав ключ. Если бы вручную проверить любые разрывы строк и исправить их.

Ответ 10

Хитрость заключается в том, чтобы использовать параметр -C (comment) для указания вашего идентификатора пользователя GCE. Похоже, что Google представила это изменение в последний раз в 2018 году.

Если пользователь Google, которому принадлежит экземпляр GCE, является [email protected] (который вы будете использовать в качестве своего имени пользователя для входа в систему), то сгенерируйте пару ключей с (например)

ssh-keygen -b521 -t ecdsa -C myname -f mykeypair

Когда вы вставляете mykeypair.pub в список открытых ключей экземпляра, вы должны увидеть, что "myname" отображается в качестве идентификатора пользователя ключа.

Установка этого параметра позволит вам использовать ssh, scp и т.д. Из командной строки.