SSH «Permission denied (publickey)»: сервер не принял ключ

Сообщение «Permission denied (publickey)» означает: соединение установлено, сервер работает, но вход по ключу не удался, а другие способы (например пароль) на нём отключены. В скобках перечислены методы, которые сервер разрешает. Если там только publickey, паролем войти нельзя.

Способ разобраться простой: запустите подключение с ключом -v, а при необходимости -vvv. Клиент подробно покажет, какие ключи он предлагал серверу и что ответил сервер. Это кратчайший путь к причине.

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

Третья: вы входите не под тем именем пользователя. Четвёртая: неверные права на каталог .ssh, на файл authorized_keys или на домашний каталог. Сервер отказывается использовать ключи, если права слишком широкие. Пятая: закрытый ключ имеет слишком открытые права на вашей машине, и клиент отказывается его применять. Шестая: формат или тип ключа не поддерживается сервером, например слишком старый алгоритм.

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

На сервере проверьте, что публичный ключ лежит в файле authorized_keys нужного пользователя, целиком в одной строке. Посмотрите права: каталог .ssh должен быть доступен только владельцу, файл с ключами тоже. Загляните в журнал службы SSH на сервере: там обычно написана точная причина отказа.

Проверьте, не включена ли на сервере настройка, разрешающая вход только определённым пользователям.

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

Добавьте правильный публичный ключ в authorized_keys нужного пользователя. Сделать это можно через консоль хостинга, панель или другой доступ. Исправьте права на каталог и файлы, а на клиенте на закрытый ключ. Явно укажите файл ключа и имя пользователя, либо пропишите их в конфигурации клиента для этого хоста.

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

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

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

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

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