Permission denied (publickey): как найти настоящую причину

Permission denied (publickey) означает одно и только одно: сервер допускает лишь аутентификацию по ключу, клиент предложил все ключи, какие у него были, и ни один из них не приняли. Почему так вышло, ошибка не сообщает, и это сделано намеренно - сервер не станет объяснять отказ тому, кто может оказаться злоумышленником. Но объяснение существует. Оно разделено между двумя местами: ssh -v на вашей стороне, который показывает, какие ключи были предложены и как ответил сервер, и журнал аутентификации на сервере, где сказано, почему был проигнорирован ключ, который должен был сработать.

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

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

Сначала сохраните себе путь внутрь#

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

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

Читаем ssh -v: история со стороны клиента#

Запустите подключение ещё раз с одним -v. Два или три (-vvv) добавляют подробности, которые при этой ошибке нужны редко, а вывод становится труднее просматривать.

$ ssh -v deploy@203.0.113.10

Важные строки неудачной попытки выглядят так:

debug1: Authenticating to 203.0.113.10:22 as 'deploy'debug1: identity file /home/alex/.ssh/id_rsa type -1debug1: identity file /home/alex/.ssh/id_ed25519 type 3debug1: Authentications that can continue: publickeydebug1: Next authentication method: publickeydebug1: Offering public key: /home/alex/.ssh/id_ed25519 ED25519 SHA256:5xM8n... agentdebug1: Authentications that can continue: publickeydebug1: No more authentication methods to try.deploy@203.0.113.10: Permission denied (publickey).

Читайте сверху вниз и задавайте себе такие вопросы.

1. Какой пользователь? as 'deploy' - это учётная запись, которую запрашивают у сервера. Если там имя пользователя вашего ноутбука, а не учётной записи на сервере, вы забыли user@ или в ~/.ssh/config нет строки User для этого хоста.
2. Какие файлы ключей существуют? type -1 означает, что файл не найден или не читается. Любое другое число значит, что клиент его загрузил. Если у нужного ключа стоит type -1, клиента этого ключа просто не было.
3. Какие ключи были предложены? Каждая строка Offering public key: - это одна попытка, с путём к файлу и отпечатком. Если установленного на сервере ключа в этом списке нет, то всё, что на сервере, пока не имеет значения - сначала исправьте клиент.
4. Как ответил сервер? После предложения строка Server accepts key: означает, что сервер нашёл этот открытый ключ в authorized_keys, и остаётся шаг с подписью. Если сразу после предложения снова идёт Authentications that can continue: publickey, сервер посмотрел и не нашёл ключ либо нашёл, но не стал ему доверять.

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

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

$ ssh-keygen -lf ~/.ssh/id_ed25519.pub              # на вашей машине$ ssh-keygen -lf /home/deploy/.ssh/authorized_keys  # на сервере, одна строка на ключ

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

Ключ, который так и не предложили#

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

Клиент OpenSSH ищет файлы со стандартными именами: id_rsa, id_ecdsa, id_ecdsa_sk, id_ed25519, id_ed25519_sk, а также всё, что есть в агенте. Ключ, сохранённый как ~/.ssh/work_server или ~/.ssh/github, невидим, пока вы не укажете его явно. Сначала сделайте это в командной строке для проверки, а затем в конфигурации, чтобы больше к этому не возвращаться:

$ ssh -i ~/.ssh/work_server -o IdentitiesOnly=yes deploy@203.0.113.10

Host web-01    HostName 203.0.113.10    User deploy    IdentityFile ~/.ssh/work_server    IdentitiesOnly yes

IdentitiesOnly yes важен и в обратную сторону. Без него клиент предлагает все ключи из агента, прежде чем дойдёт до указанного вами файла, и каждый из них засчитывается в MaxAuthTries на сервере (по умолчанию 6). Если загружено достаточно ключей, вас отключат с сообщением Too many authentication failures, хотя нужный ключ у вас есть. Выглядит это как та же проблема, но это не она.

Ещё три способа потерять нужный ключ:

• `sudo ssh` запускается от root и читает /root/.ssh, а не вашу папку. У скриптов, вызывающих ssh через sudo, у заданий cron, работающих от другого пользователя, и у CI-раннеров свои домашние каталоги и свои ключи.
• Закрытый ключ, который клиент отказывается загружать. Если файл доступен для чтения другим пользователям, клиент выводит WARNING: UNPROTECTED PRIVATE KEY FILE! и This private key will be ignored. над отладочными строками. Это исправляет chmod 600 ~/.ssh/id_ed25519.
• Не та половина. -i ~/.ssh/id_ed25519.pub указывает на открытый ключ. Свежие клиенты справляются, подбирая соответствующий закрытый файл, а более старые падают с Load key: invalid format. Направляйте -i на файл без .pub.

У пользователей PuTTY есть ещё одна ловушка: файл .ppk - это не ключ OpenSSH. В меню Conversions программы PuTTYgen можно экспортировать закрытый ключ OpenSSH, а открытый ключ для authorized_keys - это одна строка, показанная в окне программы, а не многострочный блок ---- BEGIN SSH2 PUBLIC KEY ----. Этот блок имеет формат RFC 4716, и sshd его игнорирует; если у вас есть только он, ssh-keygen -i -f key.pub преобразует его в однострочный ключ.

Не тот пользователь, не та учётная запись, не тот файл#

Ключ устанавливается для пользователя, в домашний каталог этого пользователя. Запросите другого пользователя - получите другой authorized_keys или не получите его вовсе.

Из этой таблицы следуют обычные ошибки:

• Облачные образы создают пользователя по умолчанию (ubuntu, debian, admin, ec2-user и другие, в зависимости от дистрибутива) и кладут ключ туда, часто отключив вход под root или настроив authorized_keys для root так, чтобы он выводил "please log in as ubuntu" и разрывал соединение.
• Ключ попал в вашу собственную учётную запись, а не в служебную. ssh-copy-id устанавливает ключ в ту учётную запись, под которой вы подключились. Чтобы добавить ключ для deploy, находясь под именем alex, нужно записать его в /home/deploy/.ssh/authorized_keys, а затем исправить владельца файла - об этом в следующем разделе.
• Изменён `AuthorizedKeysFile`. По умолчанию это .ssh/authorized_keys .ssh/authorized_keys2 относительно домашнего каталога. В некоторых защищённых конфигурациях его переносят в /etc/ssh/authorized_keys/%u. Проверяйте то, что использует работающий демон, а не то, что вы предполагаете:

$ sudo sshd -T | grep -Ei 'authorizedkeysfile|pubkeyauthentication|allowusers|allowgroups'

sshd -T выводит действующую конфигурацию после обработки всех Include и применения значений по умолчанию, и только эта версия имеет значение. В Debian и Ubuntu файл в /etc/ssh/sshd_config.d/ может незаметно переопределить основной, потому что sshd оставляет первое прочитанное значение для ключевого слова. Чтобы увидеть, что делает блок Match для конкретного входа, добавьте параметры подключения: sshd -T -C user=deploy,host=laptop,addr=198.51.100.7.

Наконец, проверьте саму строку ключа. Один открытый ключ - это ровно одна строка: тип, блок base64, необязательный комментарий. Если вставлять его через терминал или редактор, который переносит длинные строки, он разобьётся на две, а sshd молча пропускает испорченную строку. wc -l для файла с одним ключом должен выдать 1, а ssh-keygen -lf для него должен вывести один отпечаток, а не ошибку.

Права доступа и владелец файлов#

Это классическая серверная причина, и клиент не видит её вовсе. При StrictModes yes (значение по умолчанию) sshd отказывается использовать файл authorized_keys, если его самого, его каталог или домашний каталог выше может изменить кто-то, кроме пользователя или root. Файл, который может править любой, - это файл, в который любой может добавить свой ключ, поэтому демон считает его скомпрометированным.

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

Вторая половина - владелец. Если записать файл от имени root, через sudo nano или sudo cp, он останется принадлежать root. Восстановить всё одним махом можно так:

$ sudo chown -R deploy:deploy /home/deploy/.ssh$ sudo chmod 700 /home/deploy/.ssh$ sudo chmod 600 /home/deploy/.ssh/authorized_keys$ sudo chmod go-w /home/deploy

Если причина в этом, журнал сервера говорит об этом прямо: Authentication refused: bad ownership or modes for directory /home/deploy или то же самое для .ssh либо для файла. Отключение StrictModes убирает ошибку, но оставляет саму уязвимость на месте; лучше исправьте права. Если вы уже путались в правах на серверах другого типа, права доступа и владельцы файлов объясняют восьмеричную запись подробнее.

Типы ключей и изменение с SHA-1 для ssh-rsa#

Начиная с OpenSSH 8.8 (2021), алгоритм подписи ssh-rsa, использующий SHA-1, по умолчанию отключён и на клиенте, и на сервере. Это самая запутанная причина данной ошибки, потому что тип ключа и алгоритм подписи называются одинаково. Ключ RSA по-прежнему прекрасно работает; он просто подписывается с помощью rsa-sha2-256 или rsa-sha2-512. Проблемы начинаются, только когда одна из сторон слишком стара и не знает вариантов SHA-2.

Направлений два, и выглядят они по-разному.

Новый клиент и старый сервер. Типичные цели - старые сетевые устройства, NAS, роутеры и дистрибутивы, в которых OpenSSH старше 7.2. В -v видно, что ключ рассмотрели, а затем пропустили:

debug1: Offering public key: /home/alex/.ssh/id_rsa RSA SHA256:Qk2... explicitdebug1: send_pubkey_test: no mutual signature algorithm

no mutual signature algorithm выдаёт причину с головой. Самое чистое решение - ключ ed25519, если сервер достаточно новый, чтобы его принять (OpenSSH 6.5 или новее). Если нет, включите SHA-1 обратно только для этого одного хоста и никогда не делайте это глобально:

Host old-nas    HostName 192.168.1.20    HostKeyAlgorithms +ssh-rsa    PubkeyAcceptedAlgorithms +ssh-rsa

В клиентах старше OpenSSH 8.5 второе ключевое слово пишется PubkeyAcceptedKeyTypes; текущие версии понимают оба варианта. HostKeyAlgorithms нужен, только если собственный ключ хоста у сервера RSA и работает только с SHA-1, а на таком старом оборудовании так обычно и бывает.

Старый клиент и новый сервер. Здесь вывод клиента показывает лишь предложение и отказ, а причина записана в журнале сервера: строка о том, что алгоритм подписи (а в некоторых версиях тип ключа) ssh-rsa not in PubkeyAcceptedAlgorithms. Формулировка отличается от релиза к релизу, но ключевое слово в ней остаётся тем же. Исправлять нужно на клиенте: обновите его или переведите на ключ ed25519. Обычные подозреваемые - старые инструменты для Windows, старые Java-библиотеки SSH в программах для деплоя и резервного копирования и встроенные клиенты. Добавление +ssh-rsa на сервере включает SHA-1 обратно для всех, и это должно быть кратковременной мерой, а не решением.

Стоит знать и вот что: ключи DSA (ssh-dss) отключены по умолчанию начиная с OpenSSH 7.0, а в более поздних выпусках их поддержку убрали полностью. Ключ id_dsa не заработает с современным сервером ни при каких настройках, и единственное решение - новый ключ. То же относится к ключам RSA короче 1024 бит, которые текущий OpenSSH отклоняет сразу.

Когда мешает агент#

Агент помогает, пока не начинает мешать. Стоит узнавать три сбоя.

В агенте не те ключи или нет никаких. ssh-add -l показывает, что в нём хранится. The agent has no identities. означает, что агент запущен, но пуст; Could not open a connection to your authentication agent. означает, что в этой оболочке не задана SSH_AUTH_SOCK, и клиент вообще не может до него достучаться. Обычные причины - новые сеансы терминала, tmux, запущенный до агента, и su к другому пользователю.

$ ssh-add -l$ eval "$(ssh-agent -s)"$ ssh-add ~/.ssh/id_ed25519

Сервер принимает ключ, а агент не подписывает. Это выглядит как Server accepts key:, за которым следует sign_and_send_pubkey: signing failed ... agent refused operation. Типичные причины - аппаратный ключ, которого никто не коснулся, когда он этого ждал, агент связки ключей рабочего стола, который хочет подтверждения в диалоговом окне, так и не появившемся, или ключ, добавленный с ограниченным сроком (ssh-add -t), который истёк. В большинстве случаев помогает удалить и заново добавить ключ (ssh-add -d, затем ssh-add); на рабочих столах Linux проверка того, что у файла закрытого ключа права 600, устраняет ещё удивительно большую долю случаев.

Слишком много ключей. Об этом сказано выше, но повторить стоит, потому что случай очень частый: агент с шестью ключами исчерпывает MaxAuthTries, не дойдя до нужного. Постоянное решение - IdentitiesOnly yes с отдельным явным IdentityFile для каждого хоста.

В Windows встроенный клиент OpenSSH использует службу ssh-agent, которая по умолчанию отключена. Чтобы ssh-add вообще заработал, её тип запуска нужно сменить на автоматический в оснастке "Службы" (или командой Set-Service ssh-agent -StartupType Automatic). Git for Windows поставляется со своим отдельным OpenSSH, поэтому ключ, добавленный в один агент, не виден другому; если git не работает, а ssh работает, в первую очередь проверьте это несовпадение.

SELinux, AllowUsers и другие привратники#

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

SELinux в Fedora, RHEL, Rocky, Alma и CentOS Stream помечает файлы метками, и sshd разрешено читать только authorized_keys с меткой ssh_home_t. Каталог .ssh, созданный через mv из другого места, восстановленный из архива или скопированный на место, сохраняет прежнюю метку, и права выглядят идеально, а демону доступ запрещён.

$ ls -Z ~/.ssh/authorized_keysunconfined_u:object_r:user_home_t:s0 /home/deploy/.ssh/authorized_keys$ restorecon -Rv ~/.ssh$ sudo ausearch -m avc -ts recent

Проблема в том, что стоит user_home_t там, где должно быть ssh_home_t; restorecon сбрасывает метки к значениям политики по умолчанию. Если сам домашний каталог находится в необычном месте, например /data/home, в политике для него нет правила, и сначала нужно сообщить SELinux, что он эквивалентен /home, командой semanage fcontext -a -e /home /data/home, а затем выполнить restorecon. ausearch читает /var/log/audit/audit.log и показывает сам отказ, чего собственный журнал sshd не сделает.

`AllowUsers`, `AllowGroups`, `DenyUsers`, `DenyGroups`. Если любая из этих директив присутствует, пользователь, не подошедший под неё, получает отказ независимо от ключа. В журнале написано User deploy from 198.51.100.7 not allowed because not listed in AllowUsers, а клиент видит то же самое Permission denied (publickey), что и при отсутствующем ключе. Завести новую учётную запись и забыть про эту строку - очень частый способ потерять час.

`PermitRootLogin`, установленный в no, отклоняет root даже с действительным ключом. prohibit-password (значение по умолчанию начиная с OpenSSH 7.0) разрешает вход root только по ключу.

Оболочка и состояние учётной записи. Пользователь с оболочкой /usr/sbin/nologin проходит аутентификацию, а затем его выбрасывает, и это выглядит иначе (This account is currently not available). При UsePAM no учётной записи с заблокированным паролем в /etc/shadow тоже могут отказать во входе по ключу; в большинстве дистрибутивов Linux работает UsePAM yes, и там это не применимо.

Windows OpenSSH Server имеет собственное правило, на котором спотыкаются все. Для пользователя из группы Administrators sshd игнорирует его собственный .ssh\authorized_keys и читает вместо него C:\ProgramData\ssh\administrators_authorized_keys, причём этот файл должен быть доступен для записи только Administrators и SYSTEM:

icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

Читаем журналы сервера#

Если вывода клиента недостаточно, ответ даёт журнал сервера. Где он лежит, зависит от дистрибутива:

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

$ sudo journalctl -u ssh -f$ sudo tail -f /var/log/auth.log

Строки, которые дают ответ:

Connection closed by authenticating user deploy ... [preauth] без ничего перед ним - самый неприятный случай: учётная запись существует, файл прочитан, а ни одного из предложенных ключей в нём нет. Это возвращает вас к отпечаткам. Если задать в sshd_config LogLevel VERBOSE, демон станет записывать отпечаток каждого рассматриваемого ключа, и гадание превратится в сравнение. О том, как хранить эти журналы, когда срочная проблема решена, рассказывает статья журналы, которые стоит хранить.

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

$ sudo /usr/sbin/sshd -d -p 2222$ ssh -v -p 2222 deploy@203.0.113.10        # с вашей машины

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

Замечание о шуме: журнал аутентификации публичного сервера полон строк Invalid user от сканеров, перебирающих admin, test и oracle. Это фон, а не ваша проблема, хотя это и хороший повод поставить fail2ban перед всем, что ещё принимает пароли.

Git-хосты и SFTP: та же ошибка в других местах#

Чаще всего люди встречают эту ошибку вовсе не на сервере, а при git push. git@github.com: Permission denied (publickey). - тот же механизм с двумя особенностями: пользователь всегда git, а не имя вашей учётной записи, и ключ нужно добавить в вашу учётную запись на Git-хосте, а не в файл на сервере. Проверьте без участия Git:

$ ssh -T git@github.com

Работающий ключ отвечает приветствием с вашим именем пользователя и замечанием о том, что доступ к оболочке не предоставляется. Неработающий показывает тот же отказ, а ssh -vT git@github.com даст вам уже знакомый список предложенных ключей. Если адрес репозитория начинается с https://, ключи SSH вообще не участвуют; это вопрос токена, а не данной проблемы.

У управляемых игровых, прикладных и веб-серверов обычно нет собственного демона SSH, до которого можно добраться. Доступ к файлам на RE:NODE идёт по SFTP с учётными данными, которые выдаются для каждого сервера в панели, поэтому при отказе во входе по SFTP нужно проверять хост, порт и имя пользователя на странице этого сервера, а не файл ключа - подробности подключения есть в статье SFTP и файловый менеджер. Каждый раздел этой статьи полностью применим на VDS, где sshd настраиваете вы сами.

Чек-лист в правильном порядке#

Если нужен только порядок действий:

1. ssh -v user@host - убедитесь в имени пользователя и в том, что ваш ключ есть в строках Offering public key.
2. Если ключ не предложен, исправляйте клиент: IdentityFile, IdentitiesOnly yes, права 600 на закрытый ключ, агент.
3. Если ключ предложен и отклонён, сравните отпечатки с помощью ssh-keygen -lf с обеих сторон.
4. Проверьте владельца и права на домашний каталог, .ssh и authorized_keys.
5. Проверьте в sshd -T значения AuthorizedKeysFile, AllowUsers и PermitRootLogin.
6. Следите за журналом аутентификации во время подключения; в системах с SELinux проверьте ls -Z и ausearch.
7. Если клиент пишет no mutual signature algorithm или сервер упоминает PubkeyAcceptedAlgorithms, это то самое изменение с SHA-1 - переходите на ed25519.
8. Всё ещё не получается: sshd -d -p 2222 и прочитайте каждую строку.

Когда всё заработает, закрепите исправление в ~/.ssh/config, чтобы через месяц не разбираться с тем же самым, и проверьте остальную настройку по статье первый час на новом VDS.

FAQ#

Почему ssh-copy-id отработал, а ключ всё равно отклоняют?

ssh-copy-id корректно устанавливает ключ в ту учётную запись, под которой вы подключились, но не исправляет домашний каталог, доступный группе на запись, или неверную метку SELinux, которая была до его запуска. Поищите в журнале сервера bad ownership or modes, а в системах семейства Fedora и RHEL выполните для этого пользователя restorecon -Rv ~/.ssh.

Безопасно ли отключить StrictModes, чтобы ошибка исчезла?

Нет. StrictModes существует потому, что доступный для записи authorized_keys позволяет любому другому локальному пользователю добавить свой ключ и входить под вашим именем. Исправление прав занимает четыре команды и сохраняет защиту; отключение скрывает реальную уязвимость.

Мой ключ работал годами и перестал после обновления. Почему?

Почти всегда это изменение с SHA-1 для ssh-rsa в OpenSSH 8.8 или удаление ключей DSA. Одна из сторон обновилась, и теперь они не могут договориться об алгоритме подписи. Создайте ключ ed25519 и установите его рядом со старым; включайте ssh-rsa обратно только для отдельных хостов и только для оборудования, которое нельзя обновить.

Можно ли узнать, почему сервер меня отклонил, без доступа root?

Со стороны сервера - нет: журнал аутентификации в большинстве систем читают только root или группа adm. Но с помощью ssh -v и сравнения отпечатков вы всё равно продвинетесь большую часть пути, а затем отправьте точное время вашей попытки тому, кто администрирует сервер, чтобы он быстро нашёл соответствующую строку журнала.

Означает ли Permission denied (publickey), что мой ключ украли или сервер взломали?

Почти никогда. Это сервер делает свою работу: отклоняет ключ, которого не знает. Беспокоить вас должно предупреждение об изменении ключа хоста, а не это сообщение. Но если в authorized_keys появились ключи, которых вы не добавляли, то это совсем другая ситуация, и следующее, что стоит прочитать, - что делать, если ваш сервер взломали.