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

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

Самая быстрая полезная команда:

ssh -vvv user@your_server_ip

Ищите Authenticating to ... as 'user', затем ищите Offering public key. Если ожидаемый ключ не предлагается, исправляйте клиент. Если ожидаемый ключ предлагается и отклоняется, исправляйте серверную сторону: authorized_keys, владельца, права доступа или политику SSH-демона.

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

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

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

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

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

1. Проверка локального закрытого ключа и прав доступа

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

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

Ваш закрытый ключ часто находится в ~/.ssh/id_ed25519 или ~/.ssh/id_rsa, но многие команды используют имена, специфичные для проекта. Выведите список ваших ключей:

ls -la ~/.ssh

Не загружайте и не вставляйте закрытый ключ в authorized_keys. Серверу нужно содержимое файла .pub, а не закрытый ключ.

Проверка локальных прав доступа к файлам

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

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

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

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

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

Если вы тестируете конкретный ключ, принудительно укажите его:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod user@your_server_ip

Это предотвращает предложение агентом длинного списка несвязанных ключей.

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

Также проверьте владельца. Директория .ssh и файл authorized_keys обычно должны принадлежать учетной записи, под которой вы входите:

chown -R youruser:youruser ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Если в sshd_config включен StrictModes, OpenSSH может отклонять ключи, когда домашняя директория или путь .ssh доступны для записи неправильным пользователям.

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

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

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

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... your_public_key_string user@hostname

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

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

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

Получение вашего локального открытого ключа

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

cat ~/.ssh/id_rsa.pub

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

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

ssh-keygen -y -f ~/.ssh/id_ed25519_prod

Этот вывод должен совпадать с одной строкой в 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
  IdentitiesOnly yes

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

ssh your_server_alias

5. Проверка статуса SSH-агента

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

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

echo "$SSH_AUTH_SOCK"

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

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

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

ssh-add ~/.ssh/id_rsa

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

Если ssh-add -l показывает много несвязанных ключей, а сервер отключается после нескольких попыток, либо удалите старые ключи из агента, либо используйте IdentitiesOnly yes для этого хоста.

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 на стороне сервера (продвинутый уровень)

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

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Затем найдите блоки Match ближе к концу файла. Блок Match User, Match Group или Match Address, расположенный ниже, может переопределить более ранние настройки для конкретной тестируемой учетной записи.

После любого изменения проверьте синтаксис перед перезагрузкой:

sudo sshd -t
sudo systemctl reload sshd

В некоторых системах вместо sshd используется имя службы ssh.

Надежный порядок устранения неисправностей

Используйте подробный вывод, чтобы избежать догадок. Сначала подтвердите имя пользователя. Затем подтвердите, что клиент предлагает ожидаемый вами закрытый ключ. Затем подтвердите, что соответствующий открытый ключ находится в authorized_keys целевого пользователя. Затем проверьте владельца и права доступа. Только после того, как все это будет в порядке, стоит тратить время на sshd_config, блоки Match, контексты SELinux или ограничения учетной записи.

Этот порядок решает большинство случаев Permission denied (publickey) без случайных изменений и не позволяет ослабить безопасность SSH только ради одного срочного входа.