Как отладить сбой аутентификации SSH с использованием открытого ключа

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

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

  1. Использовал ssh-keygen -t rsa для генерации пары ключей
  2. Создал ~/.ssh/authorized_keys на сервере и поместил туда открытый ключ
  3. chmod 700 ~
  4. chmod 700 ~/.ssh
  5. chmod 600 ~/.ssh/authorized_keys

Когда я пытаюсь войти с помощью закрытого ключа, я получаю следующий вывод от ssh -vvv:

debug1: Next authentication method: publickey
debug1: Trying private key: /path/to/private-key
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey: RSA [KEY_FINGERPRINT_HERE]
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: password,publickey
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password

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

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

Что ж, “решение” этой проблемы оказалось связанным с хостом. Сервер управляется компанией под названием HybridCluster. Я до сих пор не уверен, почему, но для использования аутентификации по открытым ключам с их серверами открытый ключ необходимо добавлять через интерфейс их панели управления и не вручную в файл ~/.ssh/authorized_keys.

Я думаю, это как-то связано с тем, что они динамически меняют оборудование, так что отпечаток хоста меняется, что приводит к отклонению ключа, но я не могу сказать это точно.

В любом случае, спасибо всем, кто помог, и надеюсь, это поможет какому-то несчастному пользователю HybridCluster в будущем.

Я довольно уверенно считаю, что проблема заключается в том, что открытый ключ находится в файле authorized_keys. Ваше предположение заключается в том, что ваша хостинговая компания настроила это как AuthorizedKeyFile. Если бы у вас был root-доступ, вы бы проверили настройки вашего ssh-сервера – часто это файл sshd_config (/etc/ssh/sshd_config на debian).

Предположительная настройка по умолчанию:

AuthorizedKeysFile     %h/.ssh/authorized_keys

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

Всего наилучшего!

Был интересный случай

Authentication refused: bad ownership or modes for directory /home/user

На стороне клиента (ssh ---v) заметил, что rsa просто не принимается. Пришлось фактически отлаживать сторону sshd:

$ tail -f /var/log/auth.log

Нашел ошибку, описанную выше. Проверил права доступа к самой домашней папке – 777 по какой-то причине (папка ~/.ssh 700, а authorized_keys2 640 были в порядке). Поэтому chmod 750 /home/renard/ помогло. Так что у папки домашнего каталога также есть требования.

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

Как отладить ошибки аутентификации SSH с использованием публичного ключа

Аутентификация SSH с использованием публичного ключа — это удобный и безопасный способ входа на сервер без паролей. Однако, если вы столкнулись с проблемами при настройке такой аутентификации, не отчаивайтесь. Ниже представлен детальный процесс отладки наиболее распространенных ошибок, с которыми можно столкнуться.

1. Проверка создания ключей

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

ssh-keygen -t rsa

Эта команда создает пару ключей: приватный (id_rsa) и публичный (id_rsa.pub). Убедитесь, что вы используете именно эти ключи при попытке аутентификации.

2. Проверка файла authorized_keys

Далее, вы скопировали публичный ключ в файл ~/.ssh/authorized_keys на сервере. Убедитесь, что файл существует и содержит корректный публичный ключ. Файл должен иметь права доступа 600, а директория ~/.ssh700. Вы уже выполнили:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

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

3. Просмотр журналов

Если проблема не решена, вам стоит просмотреть журналы SSH. На сервере могут быть доступны журналы аутентификации, которые могут указывать на причину проблемы. Выполните:

tail -f /var/log/auth.log

И ищите сообщения об ошибках, связанных с аутентификацией.

4. Неправильный путь к файлу authorized_keys

Как упоминалось в обсуждениях, хостинг-провайдер может иметь особые настройки аутентификации. В вашем случае это было связано с тем, что публичный ключ должен быть добавлен через панель управления, а не вручную в файл authorized_keys. Проверьте документацию вашего хост-провайдера на предмет требований к аутентификации SSH.

5. Проверка конфигурации sshd_config

Если у вас есть возможность, проверьте файл конфигурации SSH-сервера (/etc/ssh/sshd_config). Обратите внимание на параметр AuthorizedKeysFile. Возможно, у вашего хостинг-провайдера используется другой путь для хранения файлов с ключами. Например, строка:

AuthorizedKeysFile     %h/.ssh/authorized_keys

должна быть проверена на наличие изменений.

6. Использование отладочной информации

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

ssh -vvv -i /path/to/private-key user@hostname

Заключение

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

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

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