SSH Permission denied (publickey): причины и решения

Что на самом деле говорит эта ошибка

Полное сообщение клиента это строка, которая начинается с пользователя и хоста и заканчивается словами Permission denied (publickey). Слова в скобках не являются причиной. В исходном коде клиента OpenSSH сообщение строится из списка методов аутентификации, которые, по словам сервера, ещё могут быть продолжены. Поэтому (publickey) означает, что сервер принимает только ключи, а (publickey,password) означает, что он принял бы и пароль. Какой именно ключ был неверен и почему, сообщение не говорит никогда.

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

С этой ошибкой легко спутать два других случая. Предупреждение "REMOTE HOST IDENTIFICATION HAS CHANGED" это проблема файла known_hosts, она возникает до любой попытки входа. Таймаут или "connection refused" это проблема сети или файрвола, а не ключей. Это руководство только о случае, когда соединение устанавливается, а аутентификация не проходит. Если вы настраиваете ключи впервые, начните с аутентификации по ключу и руководства по усилению защиты SSH.

Шаг 1: читаем клиентскую сторону через ssh -v

В руководстве ssh(1) сказано, что несколько параметров -v повышают подробность вывода, а максимум равен 3. Начните с одного -v и переходите к -vvv, только если вывод ничего не объясняет. Всегда указывайте имя пользователя явно через -l, чтобы точно знать, какую учётную запись вы проверяете.

ssh -v -l deploy -p 22 203.0.113.10

Формулировки ниже взяты из исходного кода клиента OpenSSH и сокращены; точный набор строк зависит от версии. Читайте вывод сверху вниз:

• "Reading configuration data" и "Applying options for ..." показывают, какие файлы конфигурации и блоки Host изменили ваши настройки. Забытая строка User или IdentityFile в ~/.ssh/config нередко становится сюрпризом.
• "identity file ... type N" перечисляет ключи, которые нашёл ssh. Тип выводится как -1, если для этой записи не удалось загрузить открытый ключ, и само по себе это не ошибка.
• "Will attempt key: PATH TYPE FINGERPRINT explicit" это список ключей, которые ssh собирается использовать. Слово explicit отмечает ключ, заданный через -i или IdentityFile, а agent отмечает ключ из ssh-agent. Если вашего ключа в списке нет совсем, клиент его даже не пробовал.
• "Skipping ... key ... corresponding algorithm not in PubkeyAcceptedAlgorithms" или "... not supported by server" означает, что ключ отброшен до отправки. Это проблема алгоритма, о ней ниже.
• "Offering public key: ..." означает, что ключ отправлен серверу на проверку. Если следующей строкой идёт очередное "Authentications that can continue", а "Server accepts key" нет, сервер не принял этот ключ для этого пользователя. Переходите к серверной стороне.
• "Server accepts key: ..." означает, что сервер нашёл ключ для этого пользователя. Если вас всё равно отклонили, сбой на шаге подписи: не прошли парольная фраза или подтверждение агента, не был нажат FIDO-ключ, либо нужен второй метод из AuthenticationMethods.
• "Trying private key: PATH" появляется для записи, у которой не загружен открытый ключ, поэтому ssh читает сам закрытый ключ, возможно, запрашивая парольную фразу.
• "No more authentication methods to try." это последняя строка перед ошибкой, с которой вы начали.

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

Шаг 2: читаем серверную сторону

Если клиент предложил верный ключ, а сервер его не принял, причину назовёт журнал сервера. sshd пишет через syslog, в руководстве по умолчанию указан канал AUTH, а LogLevel по умолчанию равен INFO. Где окажутся строки, зависит от дистрибутива, поэтому используйте журнал systemd, если он есть:

sudo journalctl -u ssh -n 50 --no-pager
sudo journalctl -u sshd -n 50 --no-pager

Один из двух юнитов существует. Ищите такие строки. Их формулировки взяты из исходного кода OpenSSH:

• Invalid user NAME from ADDRESS port N: такой учётной записи на сервере нет. Неверное имя пользователя.
• Failed publickey for NAME from ADDRESS port N ssh2: ключ пробовали и отклонили. Слова "invalid user" добавляются, если учётной записи нет.
• Authentication refused: bad ownership or modes for directory /home/NAME (или "for file ..."): StrictModes отклонил путь. См. раздел о правах.
• User NAME from ADDRESS not allowed because not listed in AllowUsers: учётную запись заблокировал список разрешённых.
• ROOT LOGIN REFUSED FROM ADDRESS port N: root заблокирован директивой PermitRootLogin.
• Could not open user 'NAME' authorized keys 'PATH': Permission denied: sshd пытался прочитать файл ключей, но открыть его не удалось. sshd пишет это на обычном уровне при любой ошибке, кроме отсутствия файла.
• User NAME not allowed because shell ... does not exist (или "is not executable", или "account is locked"): сама учётная запись непригодна для входа.

Обратите внимание на последний пробел: отсутствие файла authorized_keys записывается только на уровне debug, поэтому на уровне по умолчанию отсутствующий файл не оставляет подсказки. Именно поэтому помогает запуск в режиме отладки. Руководство sshd(8) говорит, что -d запускает сервер в режиме отладки: он выводит подробные сообщения в стандартный поток ошибок, не уходит в фон, не создаёт дочерних процессов и обрабатывает только одно соединение. Повторные -d повышают уровень, максимум 3. Запустите одноразовый экземпляр на другом порту, чтобы основной демон остался нетронутым:

sudo /usr/sbin/sshd -d -p 2222
# во втором терминале, на самом сервере:
ssh -v -p 2222 -l deploy localhost

Исходный код sshd отказывается запускаться без абсолютного пути, поэтому укажите полный путь к бинарному файлу (часто это /usr/sbin/sshd). Экземпляр читает обычный /etc/ssh/sshd_config, обрабатывает ваше единственное тестовое соединение и завершается. Проверка с самого сервера не требует открывать порт 2222 в файрволе. Если процесс сразу завершился, его сообщение об ошибке называет проблему, например отсутствующий каталог разделения привилегий. В руководстве sshd_config предупреждается, что журналирование на уровне DEBUG нарушает приватность пользователей, поэтому используйте его недолго и не оставляйте отладку включённой. Можно также вывести настройки, действующие для конкретного соединения:

sudo sshd -T -C user=deploy,addr=203.0.113.50,host=server | grep -iE '^(allowusers|allowgroups|denyusers|denygroups|permitrootlogin|pubkeyauthentication|passwordauthentication|authorizedkeysfile|strictmodes|maxauthtries|authenticationmethods) '

Как объясняет руководство, -T выводит действующую конфигурацию, а -C задаёт параметры соединения, чтобы применились блоки Match. Подробнее о файле директив в статье sshd_config.

Не то имя, не тот ключ, слишком много ключей

Неверное имя пользователя. Это самая дешёвая причина для проверки. Журнал сервера показывает "Invalid user", если такой учётной записи нет. Образы провайдеров часто создают стандартную учётную запись, отличную от root, и имя зависит от образа, поэтому уточните его в инструкции провайдера и передавайте через -l или строку User в ~/.ssh/config.

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

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh-keygen -y -f ~/.ssh/id_ed25519
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

Первая команда выводит отпечаток файла открытого ключа. Вторая выводит открытый ключ, полученный из закрытого (в руководстве -y описан как чтение файла закрытого ключа и вывод открытого), на случай, если файл .pub потерян или не совпадает; сравните тело ключа со строкой в authorized_keys. Третья перечисляет все ключи, которые принимает учётная запись. Сравните отпечаток со строкой "Offering public key". Параметры описаны в статье ssh-keygen.

Слишком много ключей. Если агент хранит много идентификаторов, ssh предлагает их по одному, а сервер считает неудачи на соединение. На пределе sshd пишет "maximum authentication attempts exceeded", а клиент выводит "Too many authentication failures", обычно ещё до того, как был опробован нужный ключ. Значение MaxAuthTries по умолчанию в sshd_config(5) равно 6. В примечаниях к выпуску OpenSSH 10.6 (2026-10-06) появился отдельный лимит со значением по умолчанию 6 для проверок "принял бы ты этот ключ", поэтому сервер версии 10.6 и новее позволяет проверить больше ключей до разрыва. Повышать лимит не нужно. Заставьте клиент предлагать только нужный ключ:

Host web1
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_web1
    IdentitiesOnly yes

Руководство ssh_config(5) описывает IdentitiesOnly как параметр для случаев, когда ssh-agent предлагает много идентификаторов, и он ограничивает ssh файлами, заданными в конфигурации или в командной строке. Посмотреть, что хранит агент, можно через ssh-add -l, и помните, что проброшенный агент добавляет свои ключи (см. проброс ssh-agent). Чтобы проверить без правки конфигурации, выполните ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_web1 -l deploy 203.0.113.10. Итоговые настройки, которые применит ssh, выводит ssh -G web1: по руководству, команда печатает конфигурацию после вычисления блоков Host и Match. Помните, что для большинства директив действует первое полученное значение, а записи IdentityFile накапливаются.

Файл ключа, права и владелец

Тот файл и та учётная запись. По умолчанию sshd читает .ssh/authorized_keys и .ssh/authorized_keys2 в домашнем каталоге той учётной записи, под которой вы входите. Ключ, добавленный в файл root, не работает для deploy. Формат authorized_keys это один ключ на строку (пустые строки и строки, начинающиеся с #, считаются комментариями), а раздел о формате файла в руководстве sshd перечисляет поля: параметры, тип ключа, ключ в base64 и комментарий. Ключ, вставленный в две строки или в файл с чуть неверным именем, просто не является ключом. Пока вход по паролю ещё работает, ssh-copy-id добавит ключ в нужный файл за вас.

Права. В руководстве sshd сказано: если файл, каталог ~/.ssh или домашний каталог пользователя доступны на запись другим пользователям, файл мог быть изменён или подменён посторонними, и sshd не станет его использовать, если только StrictModes не выставлен в no. Значение StrictModes по умолчанию yes. Рекомендуемые права из руководства: для файла чтение и запись для пользователя и ничего для остальных, для каталога чтение, запись и выполнение для пользователя и ничего для остальных. В числах это 600 и 700. Исходный код OpenSSH показывает, что именно проверяется: файл и каждый каталог вплоть до домашнего должны принадлежать пользователю (или root) и не должны быть доступны на запись группе или остальным. Поэтому доступного группе на запись домашнего каталога достаточно, чтобы сломать вход по ключу.

sudo chown -R deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
namei -l /home/deploy/.ssh/authorized_keys

Последняя команда запускает namei в длинном формате, который показывает биты прав и владельца каждого элемента пути, так что неверный каталог сразу заметен. Не "исправляйте" это через StrictModes no и не делайте всё доступным всем на запись. Это снимает защиту от подкладывания чужого ключа другим локальным пользователем. Исправьте именно права. Основное правило описано в статье authorized_keys и в исходном коде OpenSSH, функция safe_path.

Нестандартные домашние каталоги. Зашифрованные или сетевые домашние каталоги, которые не смонтированы в момент, когда sshd ищет файл, дают тот же симптом "ключ не найден". Это видно по строке "Could not open user" в журнале (см. выше) и при запуске в режиме отладки. Убедитесь, что домашний каталог действительно доступен до входа.

Правила sshd_config, блокирующие вход по ключу

Если ключ и файлы в порядке, следующий кандидат это конфигурация сервера. Читайте действующие значения через sshd -T (показано выше), а не сам файл, потому что для ключевого слова действует первое полученное значение, а файлы Include и блоки Match могут переопределить то, что вы правили.

• PubkeyAuthentication. Значение по умолчанию в руководстве yes. Если любая строка, в том числе в подключённом файле, ставит no, ключи не принимаются вообще.
• PasswordAuthentication отключён, рабочего ключа нет. Значение по умолчанию yes, а на усиленных серверах его ставят в no. Тогда "Permission denied (publickey)" это правильное поведение: ключ остаётся единственным входом. Чините ключ. Не включайте пароли обратно в спешке, см. PasswordAuthentication.
• AuthorizedKeysFile. Значение по умолчанию в руководстве .ssh/authorized_keys .ssh/authorized_keys2, допускаются подстановки %h (домашний каталог) и %u (пользователь). Если конфигурация указывает в другое место, например в общий каталог, файл в домашнем каталоге не читается вовсе. Проверьте командой sudo sshd -T | grep -i authorizedkeysfile.
• AllowUsers, DenyUsers, AllowGroups, DenyGroups. По руководству, если задан AllowUsers, вход разрешён только для подходящих имён, а пользователи, совпавшие с DenyUsers, в AllowUsers даже не проверяются. Группы работают так же. В журнале строка "not allowed because not listed in AllowUsers". Подробнее в статье AllowUsers.
• PermitRootLogin. Значение по умолчанию в руководстве prohibit-password: для root отключены вход по паролю и keyboard-interactive, а ключи по-прежнему работают. При no root отклоняется при любых предъявленных данных. При forced-commands-only ключ работает, только если в его записи есть параметр command. Строка отказа: "ROOT LOGIN REFUSED FROM". См. PermitRootLogin и учтите, что root должен пройти и любой список AllowUsers.
• AuthenticationMethods. Руководство описывает его как методы, которые все должны быть успешно пройдены до предоставления доступа. Значение вроде publickey,password означает, что одного верного ключа недостаточно. Безопасное внедрение показано в руководстве по двухфакторной аутентификации SSH.
• Заблокированная учётная запись или неверная оболочка. sshd пишет "User NAME not allowed because ..." с причиной, как в разделе о сервере.

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

sudo ausearch -m avc -ts recent
restorecon -Rvn ~/.ssh
restorecon -Rv ~/.ssh

По руководству ausearch(8), -m выбирает тип записи, а recent означает десять минут назад. По руководству restorecon(8), утилита исправляет несогласованные метки, -R работает рекурсивно, -v показывает изменения, а -n только проверяет. Запускайте проверку от имени учётной записи, чьи файлы изучаете. Отказанное открытие видно в журнале sshd как строка "Could not open user".

Типы ключей, алгоритмы подписи и FIDO-ключи

RSA и SHA-1. В примечаниях к выпуску OpenSSH 8.8 сказано, что в этом выпуске по умолчанию отключены RSA-подписи с хешем SHA-1, потому что SHA-1 криптографически взломан. Там же сказано, что заменять ключи ssh-rsa не нужно: существующие RSA-ключи автоматически используют более стойкие подписи SHA-2, где это возможно, а OpenSSH поддерживает их начиная с 7.2. Проблемы возникают, когда на одном конце старая реализация SSH, знающая только форму с SHA-1. Тогда клиент пишет строку "Skipping" или сервер отказывает, и вы видите обычное сообщение об отказе. Для одного старого хоста примечания предлагают временное решение в ~/.ssh/config и рекомендуют переводить устаревшие системы на ключи ECDSA или Ed25519:

Host old-host
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Руководство ssh_config(5) объясняет, что ведущий + добавляет к списку по умолчанию, - удаляет, а ^ ставит в начало, и что ssh -Q PubkeyAcceptedAlgorithms перечисляет то, что поддерживает ваш клиент. На сервере sudo sshd -T | grep -i pubkeyacceptedalgorithms покажет, что он принимает. Лучше сгенерировать новый ключ Ed25519 (ssh-keygen -t ed25519), чем поддерживать жизнь SHA-1.

Короткие RSA-ключи. В OpenSSH 9.1 появилась директива RequiredRSASize, задающая минимальную длину RSA-ключа. В руководстве sshd_config значение по умолчанию равно 1024 битам, а ключи короче лимита игнорируются при аутентификации пользователя. Поэтому очень старый короткий RSA-ключ может перестать работать после обновления без очевидного сообщения.

FIDO-ключи (sk). В OpenSSH 8.2 добавлены типы ключей ecdsa-sk и ed25519-sk для аппаратных токенов FIDO/U2F через libfido2. Таким ключам нужен физический токен. Если он не подключён, вы не коснулись его, когда он мигал, или пропустили PIN, которого требует -O verify-required, вход не удаётся. Исходный код сервера пишет "user presence (authenticator touch) requirement not met", когда касание отсутствует. Сервер может также требовать касание или проверку для всех ключей через PubkeyAuthOptions. В примечаниях к 8.2 предупреждается, что аппаратная поддержка Ed25519 встречается реже, чем у типа ECDSA. Если ноутбук заменили, а файл ключа потерян, по руководству ssh-keygen параметр -K скачивает резидентные ключи с аутентификатора в текущий каталог, но только для ключей, созданных с параметром resident. Обоим концам нужен OpenSSH 8.2 или новее, проверьте ssh -V. Подробнее в руководстве по двухфакторной аутентификации SSH.

Порядок диагностики: что проверять и в какой последовательности

1. Выполните ssh -v -l username your-server и прочитайте последние двадцать строк. Убедитесь, что имя пользователя это нужная вам учётная запись.
2. Есть ли ваш ключ в строках "Will attempt key" и затем "Offering public key"? Если нет, чините клиент: путь IdentityFile, права закрытого ключа (chmod 600), ssh-add -l или строку "Skipping ... algorithm".
3. Видите "Too many authentication failures"? Добавьте IdentitiesOnly yes и один IdentityFile для этого хоста.
4. Видите "Server accepts key", а вход всё равно не проходит? Смотрите шаг подписи: парольная фраза, подтверждение агента, касание или PIN для FIDO либо второй метод в AuthenticationMethods.
5. Ключ предлагался, но не был принят? Прочитайте журнал сервера: строки из шага 2 (Invalid user, Authentication refused, not allowed, ROOT LOGIN REFUSED, Could not open).
6. Нет показательной строки? Сравните отпечаток ключа с authorized_keys нужной учётной записи и проверьте AuthorizedKeysFile через sshd -T.
7. Проверьте права через namei -l: домашний каталог, .ssh и файл должны принадлежать пользователю и не быть доступными на запись группе или остальным.
8. Сравните действующую конфигурацию через sshd -T -C для этого пользователя и адреса.
9. Всё ещё неясно? Запустите одноразовый отладочный демон на порту 2222 и прочитайте его вывод во время одного подключения.
10. Если войти не удаётся совсем и другой сессии нет, остановитесь и воспользуйтесь консолью провайдера.

Чек-лист профилактики и когда пора идти в консоль провайдера

Большинство таких сбоев вы создаёте себе сами при смене конфигурации, поэтому чек-лист о том, как делать изменения безопасно:

• Держите вторую SSH-сессию открытой, пока меняете sshd_config, выполняйте sudo sshd -t перед перезагрузкой и проверяйте совершенно новый вход, прежде чем закрыть старый.
• Создавайте .ssh (700) и authorized_keys (600) с верным владельцем при заведении учётной записи и никогда не оставляйте домашний каталог доступным на запись группе или остальным.
• Используйте один ключ на человека и устройство с понятным комментарием и записывайте отпечатки, чтобы потом их проверять.
• Для каждого хоста указывайте в ~/.ssh/config строки IdentityFile и IdentitiesOnly yes, а не полагайтесь на то, что хранит агент.
• Добавляйте учётную запись в AllowUsers или AllowGroups до включения списка и не забывайте учётные записи автоматизации.
• Отключайте PasswordAuthentication только после того, как вход по ключу проверен из новой сессии.
• Храните запасной ключ администратора или второй FIDO-токен в надёжном месте и заранее узнайте, как войти в консоль провайдера.
• Следите за журналом: повторные неудачи с вашего же адреса тоже могут привести к блокировке, см. защиту SSH от перебора.

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

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