Устранение проблем с «Permission Denied (publickey)» при доступе по SSH

Устранение проблем с SSH: Ошибка «Permission Denied (publickey)»

При попытке подключения к удаленному серверу через SSH ошибка «Permission Denied (publickey)» (Отказано в доступе: публичный ключ) может стать досадным препятствием. Эта ошибка конкретно указывает на то, что сервер отклонил ваше соединение, поскольку не смог аутентифицировать вас с помощью вашего публичного ключа. В отличие от аутентификации по паролю, криптография с открытым ключом полагается на пару ключей: закрытый ключ, который хранится в секрете на вашей локальной машине, и открытый ключ, размещенный на сервере. Это руководство поможет вам разобраться в распространенных причинах этой ошибки и предоставит подробные шаги по ее диагностике и устранению, обеспечивая безопасный и бесперебойный доступ по SSH.

Понимание процесса аутентификации по публичному ключу SSH имеет решающее значение для эффективного устранения неполадок. Когда вы пытаетесь подключиться, ваш SSH-клиент предъявляет ваш публичный ключ серверу. Затем сервер проверяет, авторизован ли этот публичный ключ для вашей учетной записи пользователя. Если да, сервер шифрует вызов с помощью вашего публичного ключа и отправляет его обратно. Ваш клиент, обладающий соответствующим закрытым ключом, расшифровывает вызов и отправляет ответ обратно на сервер. Если ответ правильный, аутентификация успешна. Ошибка «Permission Denied (publickey)» означает, что этот обмен данными потерпел неудачу на каком-то этапе.

Распространенные причины ошибки «Permission Denied (publickey)»

Ошибка «Permission Denied (publickey)» может быть вызвана несколькими проблемами конфигурации. Выявление первопричины часто включает систематическую проверку следующих компонентов:

Неправильные разрешения файлов: SSH очень чувствителен к разрешениям файлов и каталогов по соображениям безопасности. Неправильные разрешения в вашем локальном каталоге ~/.ssh, файле закрытого ключа, или в каталоге ~/.ssh и файле authorized_keys на стороне сервера могут препятствовать аутентификации.
Отсутствие или неправильная запись в файле authorized_keys: Файл authorized_keys на сервере должен содержать правильный публичный ключ для пользователя, от имени которого вы пытаетесь войти. Если ключ отсутствует, имеет неправильный формат или связан с неверным пользователем, аутентификация завершится неудачей.
Несоответствие пары ключей: Ваш SSH-клиент может предлагать неверный закрытый ключ, или соответствующий публичный ключ может отсутствовать в файле authorized_keys на сервере.
Проблемы с SSH Agent: Если вы используете SSH-агент, он может быть неправильно загружен вашим закрытым ключом или неправильно сконфигурирован.
Конфигурация SSH на стороне сервера: Хотя это менее распространено для этой конкретной ошибки, конфигурация демона SSH на сервере (sshd_config) может содержать специфические ограничения на аутентификацию по публичному ключу.

Пошаговое руководство по устранению неполадок

Давайте углубимся в практические шаги по диагностике и исправлению этих проблем.

1. Проверьте локальный закрытый ключ и разрешения

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

Проверка наличия закрытого ключа

Ваш закрытый ключ обычно находится в ~/.ssh/id_rsa (или id_ed25519, id_dsa и т. д.).

Проверка разрешений локального файла

Каталог ~/.ssh и ваш файл закрытого ключа должны иметь строгие разрешения для предотвращения несанкционированного доступа.

Каталог ~/.ssh: Должен быть 700 (drwx------).
Файл закрытого ключа (например, id_rsa): Должен быть 600 (-rw-------).

Используйте команду chmod для установки правильных разрешений:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

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

2. Проверьте конфигурацию `authorized_keys` на стороне сервера

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

Доступ к серверу (если возможно)

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

Проверка расположения файла `authorized_keys`

Файл authorized_keys обычно расположен по адресу ~/.ssh/authorized_keys в домашнем каталоге пользователя, от имени которого вы пытаетесь войти.

Проверка разрешений файлов на стороне сервера

Подобно клиентской стороне, разрешения на стороне сервера имеют решающее значение:

Каталог ~/.ssh на сервере: Должен быть 700 (drwx------).
Файл authorized_keys на сервере: Должен быть 600 (-rw-------).

Убедитесь, что эти разрешения установлены правильно на сервере:

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

Проверка содержимого `authorized_keys`

Откройте файл ~/.ssh/authorized_keys с помощью текстового редактора (например, nano, vim). Каждый публичный ключ должен находиться в одной строке. Убедитесь, что публичный ключ, который вы намерены использовать, присутствует и правильно отформатирован. Он должен начинаться с ssh-rsa, ssh-ed25519 или аналогичного, за которым следует длинная строка символов, и, возможно, комментарий.

Пример записи в файле authorized_keys:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... ваш_строка_публичного_ключа user@hostname

Важно: Не добавляйте свой закрытый ключ в authorized_keys. Здесь должен быть только публичный ключ.

3. Убедитесь, что добавлен правильный публичный ключ

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

Получение локального публичного ключа

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

cat ~/.ssh/id_rsa.pub

Эта команда выведет ваш публичный ключ. Тщательно сравните этот вывод с записью в файле ~/.ssh/authorized_keys на сервере. Даже одна опечатка или отсутствие символа приведет к сбою аутентификации.

Совет: Быстрый способ добавить ваш публичный ключ, если у вас есть доступ к серверу по паролю, — использовать ssh-copy-id.

ssh-copy-id user@your_server_ip

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

4. Укажите правильный закрытый ключ (если он не по умолчанию)

Если вы используете закрытый ключ, не указанный по умолчанию (например, ~/.ssh/my_other_key), вам необходимо сообщить вашему SSH-клиенту, какой ключ использовать.

Использование флага `-i`

Вы можете указать файл идентификатора (закрытый ключ) с помощью опции -i:

ssh -i ~/.ssh/my_other_key user@your_server_ip

Настройка `~/.ssh/config`

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

Создайте или отредактируйте файл ~/.ssh/config на вашей локальной машине и добавьте запись, подобную этой:

Host your_server_alias
  HostName your_server_ip_or_domain
  User your_username
  IdentityFile ~/.ssh/my_other_key

Затем вы сможете подключаться, просто используя:

ssh your_server_alias

5. Проверьте состояние SSH Agent

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

Проверка, запущен ли Агент

echo "$SSH_AUTH_SOCK"

Если это выводит путь, агент, скорее всего, запущен. Если вывод пуст, вам может потребоваться запустить его.

Добавление ключа в Агент

Если ваш ключ не загружен, добавьте его:

ssh-add ~/.ssh/id_rsa

Если вас просят ввести кодовую фразу, введите ее. Вы можете проверить, какие ключи добавлены, с помощью ssh-add -l.

6. Отладка с помощью режима подробного вывода

У SSH есть режим подробного вывода (-v, -vv или -vvv для повышения уровня детализации), который может предоставить бесценные подсказки о том, где именно терпит неудачу процесс аутентификации.

ssh -vvv user@your_server_ip

Изучите вывод на предмет сообщений, связанных с аутентификацией по ключу, предложением ключей и ответами сервера. Это часто прямо указывает на проблему.

Пример фрагмента подробного вывода, указывающего на сбой publickey:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: read PEM private key file /home/user/.ssh/id_rsa
debug1: failed to use sshkey: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

Этот вывод может указывать на то, что клиент попытался использовать id_rsa, но потерпел неудачу, а затем перешел к другим методам.

7. Обзор `sshd_config` на стороне сервера (расширенный уровень)

Хотя это менее распространено для ошибок, специфичных для publickey (обычно появляются другие ошибки), стоит отметить файл конфигурации демона SSH на сервере (/etc/ssh/sshd_config). Убедитесь, что PubkeyAuthentication yes не закомментирован и установлен в yes. После внесения любых изменений служба SSH должна быть перезагружена или перезапущена (например, sudo systemctl reload sshd или sudo systemctl restart sshd).

Резюме и лучшие практики

Устранение проблем с ошибкой SSH «Permission Denied (publickey)» включает методическую проверку конфигураций как клиента, так и сервера. Наиболее частые причины связаны с неправильными разрешениями файлов для файлов ~/.ssh и authorized_keys, а также с несоответствием между публичным ключом на сервере и закрытым ключом на клиенте.

Ключевые выводы:

Разрешения имеют первостепенное значение: Всегда убеждайтесь, что ~/.ssh имеет права 700, а закрытые ключи/authorized_keys — 600 как на клиенте, так и на сервере.
Точность публичного ключа: Дважды проверьте, что точный публичный ключ присутствует в файле authorized_keys на сервере.
Используйте ssh-copy-id: По возможности, это самый безопасный и простой способ настройки аутентификации по публичному ключу.
Подробный режим: Используйте ssh -vvv для получения подробного вывода диагностики.

Следуя этим шагам, вы сможете диагностировать и устранить большинство проблем с «Permission Denied (publickey)», восстановив безопасный удаленный доступ к вашим серверам.