Отказано в доступе (publickey,gssapi-keyex,gssapi-with-mic)

Вопрос или проблема

Хорошо, я пробовал это несколько раз, и я уверен, что это очень тривиально, но: я пытаюсь подключиться по SSH через командную строку на Ubuntu к своей ВМ (Centos6) с помощью пары ключей RSA, которую я создал с помощью key-gen.

Я создал пару ключей и добавил открытый ключ в файл authorized_keys, а также изменил разрешения на 600. После того как я скопировал закрытый ключ на Ubuntu и попытался подключиться с его помощью, я всегда получал:

Доступ запрещен (publickey,gssapi-keyex,gssapi-with-mic).

Я уже пробовал это 3 раза, и безрезультатно. Я могу пропинговать его, но не могу понять, почему не принимается ключ, который я создал. Есть ли какие-либо предложения?

Запустите ssh в.verbose режиме (добавьте столько -v, сколько вам нужно) и попробуйте выяснить причину.

Например:

ssh -vvv user@host

Вы получите отладочный вывод, который поможет вам выяснить причину.

Сначала сгенерируйте пару ключей на вашем компьютере с Ubuntu.

Затем скопируйте содержимое сгенерированного .pub файла в вашу папку ssh (~/.ssh/id_rsa) и вставьте его в файл username/.ssh/id_rsaauthorized_keys на новой строке на вашем CentOS для конкретного пользователя, с которым вы входите.

У меня была такая же проблема на ClearOS 7.2, когда я пытался выполнить вход через SSH с использованием RSA из OSX.

Оказалось, что мне пришлось добавить имя файла своего закрытого ключа (того, который находится на клиентской системе, в данном случае OSX) в файл /etc/ssh/ssh_config (это файл конфигурации ssh-клиента на клиентской машине). В противном случае он просто не будет искать этот файл, даже несмотря на то, что он начинается с id_rsa.

Добавленная строка была:

IdentityFile ~/.ssh/id_rsa.somecomputer

“somecomputer” – это любая часть имени файла, которую у вас может быть.

У меня была такая же проблема, я решил её следующим образом:

На ssh-сервере я раскомментировал и установил на yes следующие значения в /etc/ssh/sshd_config

 RSAAuthentication yes
 PubkeyAuthentication yes

И затем:

sudo service sshd restart

Вы можете выполнить команду tail -f /var/log/auth.log, если она существует на сервере, и попробовать войти снова, вы сможете увидеть причину сбоя, которая доступна в логе. Если нет, увеличьте уровень подробности в конфигурационном файле SSH-демона до DEBUG и попробуйте снова. Часто это связано с разрешениями файлов.

Я сталкиваюсь с той же проблемой, для меня сначала измените конфигурацию сервера (CentOS 7.9) sshd и разрешите вход по паролю:

PasswordAuthentication yes

и перезапустите sshd:

systemctl restart sshd

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

ssh -p 22 root@{server-ip} 'mkdir -p .ssh && cat >> ~/.ssh/authorized_keys' < ~/.ssh/id_rsa.pub

У меня была такая же проблема раньше – мой ключ был перемещен в другую папку, и я не обновил файл ssh_config.

Ответ или решение

Ошибка «Permission denied (publickey,gssapi-keyex,gssapi-with-mic)» при подключении по SSH часто возникает из-за неправильной настройки ключей SSH, их расположения или конфигурации сервера. Вот несколько шагов и решений, которые могут помочь вам устранить эту проблему.

1. Проверка генерации ключей

Прежде всего, убедитесь, что вы правильно сгенерировали ключи RSA на вашей Ubuntu-машине. Для этого выполните команду:

ssh-keygen -t rsa -b 2048

Это создаст пару ключей — приватный (id_rsa) и публичный (id_rsa.pub), которые по умолчанию будут находиться в папке ~/.ssh/.

2. Добавление публичного ключа на сервер

Убедитесь, что вы скопировали содержимое файла id_rsa.pub и добавили его в файл authorized_keys на вашем сервере CentOS. Для этого используйте следующую команду:

cat ~/.ssh/id_rsa.pub | ssh user@centos-server 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

Также не забудьте проверить правильность прав доступа к файлу authorized_keys:

chmod 600 ~/.ssh/authorized_keys

3. Настройка прав доступа

SSH требует строгих прав доступа для файлов и директорий, связанных с ключами. Убедитесь, что:

  • Директория ~/.ssh на сервере имеет права 700:
chmod 700 ~/.ssh
  • Файл ~/.ssh/authorized_keys имеет права 600:
chmod 600 ~/.ssh/authorized_keys

4. Проверка конфигурации SSH-сервера

Убедитесь, что в файле конфигурации SSH-сервера /etc/ssh/sshd_config включены параметры аутентификации по публичному ключу. Найдите строку:

# RSAAuthentication yes
# PubkeyAuthentication yes

И замените их на:

RSAAuthentication yes
PubkeyAuthentication yes

После внесения изменений перезапустите SSH-сервер:

sudo service sshd restart

5. Использование подробного вывода

Для более детальной диагностики выполните SSH-команду с высоким уровнем подробности:

ssh -vvv user@centos-server

Эта команда даст вам подсказки о том, почему аутентификация не проходит.

6. Проверка логов

Если проблема все еще не решена, посмотрите на лог-файлы аутентификации на сервере. Испробуйте команду:

tail -f /var/log/auth.log

Или, если вы используете CentOS:

tail -f /var/log/secure

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

7. Проверка конфигурации клиента

Если вы используете нестандартное имя для вашего приватного ключа, убедитесь, что оно указано в конфигурационном файле SSH-клиента. Откройте файл ~/.ssh/config и добавьте следующее:

Host centos-server
    IdentityFile ~/.ssh/id_rsa.your_custom_name

8. Дополнительные проверки

  • Убедитесь, что ваш сервер доступен и вы можете его пинговать.
  • Порой ряд настроек на сервере или в сети (например, файрволы) могут блокировать доступ.

Заключение

Следуя вышеизложенным шагам, вы должны быть в состоянии диагностировать и решить проблему с аутентификацией по SSH. Если трудности продолжаются, возможно, стоит проверить настройки сети или обратиться к администратору сервера для получения помощи.

Оцените материал
Добавить комментарий

Капча загружается...