SSH Permission denied (publickey): проверяем sshd_config и ~/.ssh без лишней боли

Ошибка Permission denied (publickey) — одна из самых частых при подключении к Linux-серверу. И почти всегда она решается проверкой трёх вещей: какой ключ вы реально отправляете, разрешён ли вход по ключам на стороне сервера, и корректны ли права/владельцы на ~/.ssh и authorized_keys. Ниже — практичная «админская» инструкция: от быстрой диагностики до тонких случаев с Match-блоками, SELinux и банально «не тем пользователем».

Как читать ошибку Permission denied (publickey)

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

Самые типовые причины:

• клиент не предлагает нужный ключ (или предлагает другой);
• ключ не лежит в ~/.ssh/authorized_keys нужного пользователя;
• права на ~/.ssh или authorized_keys слишком «широкие», и sshd игнорирует файл;
• в sshd_config отключены ключи или их отключает Match для вашего пользователя/IP;
• вы логинитесь не тем пользователем (ключ лежит в одном home, а входите в другой);
• подключаетесь не к тому серверу/порту (часто при NAT/пробросах/балансировщиках).

Шаг 1. Диагностика с клиента: ssh -vvv и какой ключ реально уходит

Начинайте с максимальной «болтливости» клиента: так вы увидите, какие ключи SSH нашёл, что реально предложил серверу и что было отвергнуто.

ssh -vvv user@server

Если порт нестандартный:

ssh -vvv -p 2222 user@server

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

• identity file ... — какие ключи клиент нашёл локально;
• Offering public key — какие ключи реально предлагаются серверу;
• Server accepts key (успех) или ошибки вроде no mutual signature supported, key type ... not in PubkeyAcceptedAlgorithms.

Чтобы принудительно указать конкретный ключ (часто сразу вскрывает проблему выбора ключа):

ssh -vvv -i ~/.ssh/id_ed25519 user@server

Если с -i всё заработало — проблема обычно на стороне клиента: по умолчанию выбирался не тот ключ, либо ssh-agent подсовывал набор, в котором нужный ключ не доходил до попытки.

Проверьте, что ключ существует и читается

ls -la ~/.ssh
ssh-keygen -lf ~/.ssh/id_ed25519.pub

Если у вас есть только приватный ключ, а публичный файл потерялся, публичную часть можно восстановить из приватной:

ssh-keygen -y -f ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519.pub

ssh-agent: полезен, но иногда мешает

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

Посмотреть ключи в агенте:

ssh-add -l

Сбросить все ключи из агента (делайте осознанно, если вы работаете с несколькими серверами):

ssh-add -D

Шаг 2. Убедиться, что вы логинитесь тем пользователем

Неверный пользователь — банальщина, которая выглядит как «магия»: ключ добавили в /home/admin/.ssh/authorized_keys, а подключаются как root или как другой аккаунт.

Быстрый чек:

• какой пользователь указан в команде (ssh user@host);
• какой пользователь задан в ~/.ssh/config (если используете);
• разрешён ли этот пользователь политиками сервера (например, вход под root часто запрещён).

Если у вас есть консоль/панель/второй канал — на сервере проверьте, в какой home реально должен лежать ключ: /home/USER/.ssh/authorized_keys или /root/.ssh/authorized_keys.

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

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Шаг 3. Проверка ~/.ssh и authorized_keys на сервере: владельцы и права

OpenSSH строг к правам. Если каталог ~/.ssh или файл authorized_keys доступны на запись кому-то кроме владельца (или у файлов/директорий «подозрительные» владельцы), sshd может просто игнорировать ключи.

На сервере выполните под нужным пользователем (или через sudo):

ls -ld ~
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

Рекомендуемые права (типовой безопасный минимум):

• домашний каталог: часто 755 или 750 (жёсткого стандарта нет, но опасна групповая/общая запись);
• ~/.ssh: 700;
• ~/.ssh/authorized_keys: 600 (иногда проходит 640, но лучше 600);
• владелец и группа — пользователь, под которым вы входите.

Команды для исправления (пример для пользователя user):

sudo chown -R user:user /home/user/.ssh
sudo chmod 700 /home/user/.ssh
sudo chmod 600 /home/user/.ssh/authorized_keys

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

Проверьте содержимое authorized_keys без «невидимых» проблем

В authorized_keys одна строка — один публичный ключ. Ошибка часто в переносах, лишних пробелах или в том, что вы случайно вставили не публичный ключ.

Признаки проблемы:

• в файл попал приватный ключ (начинается с -----BEGIN) — так нельзя;
• ключ скопирован с переводами строк посередине base64-части;
• в начале строки есть лишние символы;
• ключ добавлен не тому пользователю.

Быстрая проверка формата: начало строки обычно ssh-ed25519, реже ecdsa-sha2-nistp256 или ssh-rsa (устаревает). Далее — длинная base64-часть и опциональный комментарий.

Шаг 4. Проверка sshd_config: PubkeyAuthentication, AuthorizedKeysFile, ограничения пользователей

Если с правами и пользователем всё хорошо, переходите к конфигурации sshd. Обычно это /etc/ssh/sshd_config плюс include-файлы в /etc/ssh/sshd_config.d/.

Проверьте параметры, которые чаще всего ломают вход по ключам:

• PubkeyAuthentication — должно быть yes;
• AuthorizedKeysFile — куда именно sshd смотрит ключи (по умолчанию .ssh/authorized_keys относительно home);
• PasswordAuthentication — может быть no (это нормально), но тогда ключи обязаны работать;
• PermitRootLogin — важно, если входите как root (часто стоит prohibit-password или no);
• AllowUsers/DenyUsers, AllowGroups/DenyGroups — не блокируют ли ваш аккаунт.

Главная ловушка: Match-блоки, которые переопределяют настройки

Даже если в начале файла всё выглядит правильно, ниже может быть блок Match, который «в точке входа» отключает ключи для конкретного пользователя, группы или адреса.

Пример (как он выглядит в конфиге):

Match User someuser
  PubkeyAuthentication no

Посмотреть итоговую конфигурацию sshd (effective config)

Когда есть include-файлы и Match, удобнее не «глазами искать», а вывести эффективные значения:

sudo sshd -T

И, если версия OpenSSH поддерживает, привязать вывод к конкретному контексту (пользователь, адрес):

sudo sshd -T -C user=user,host=server,addr=203.0.113.10

В выводе ищите pubkeyauthentication, authorizedkeysfile, passwordauthentication, а также ограничения по пользователям/группам.

Шаг 5. Смотреть логи sshd: там обычно написано «почему»

Если у вас есть доступ к серверу через консоль/панель/второго пользователя — логи быстрее любых догадок.

На системах с systemd:

sudo journalctl -u ssh -n 200 --no-pager

На некоторых дистрибутивах юнит называется sshd:

sudo journalctl -u sshd -n 200 --no-pager

Если используются классические файлы логов:

sudo tail -n 200 /var/log/auth.log

или:

sudo tail -n 200 /var/log/secure

Типовые подсказки из логов:

• Authentication refused: bad ownership or modes for directory — проблема прав/владельца на домашний каталог или .ssh;
• Failed publickey for user — ключ предлагали, но он не подошёл (в authorized_keys нет нужного);
• Could not open authorized keys — неверный путь, нет прав, или файла нет;
• User user not allowed because not listed in AllowUsers — ограничение доступа;
• key type ssh-rsa not in PubkeyAcceptedAlgorithms — запрещённый/устаревший алгоритм.

Частые «неочевидные» причины

1) Устаревший RSA-ключ и ограничения алгоритмов

Если политики ужесточили алгоритмы, ssh-rsa (особенно с SHA-1) может быть запрещён. В ssh -vvv это выглядит как ошибки по алгоритмам, а в логах часто всплывает PubkeyAcceptedAlgorithms.

Практичное решение — сгенерировать современный ключ (обычно ed25519) и добавить его на сервер:

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519

2) Неверный AuthorizedKeysFile

Иногда AuthorizedKeysFile переопределяют, например на путь вида /etc/ssh/authorized_keys/%u или на несколько мест. В итоге вы добавляете ключ «в привычное место», а sshd его не читает.

Проверьте фактическое значение через sshd -T, затем проверьте существование файлов/каталогов, права и владельцев.

3) Домашний каталог и ACL/UID-несовпадения

Если логи упираются в bad ownership or modes, смотрите не только ~/.ssh, но и сам home-каталог, а также ACL и соответствие UID (актуально при LDAP/NIS и миграциях).

Минимальный набор проверок:

id user
getfacl -p /home/user 2>/dev/null
getfacl -p /home/user/.ssh 2>/dev/null

4) SELinux

При включённом SELinux даже корректные POSIX-права могут не помочь из-за контекстов. Быстрый тест:

getenforce

Если подозрения подтверждаются, смотрите audit-логи и проверяйте контексты у ~/.ssh и authorized_keys. Меняйте политику аккуратно: обходные решения «лишь бы заработало» часто снижают безопасность.

5) Вы подключаетесь не туда (другой сервер, другой порт)

Симптомы очень похожи на мистику: «вчера работало, сегодня publickey». На деле мог поменяться DNS, IP, проброс порта, или вы попали на другой узел кластера, где ключи ещё не раскатаны.

Проверьте, что клиент видит ожидаемый хост-ключ для этого имени:

ssh-keygen -F server

И на сервере убедитесь, что sshd слушает нужный порт:

sudo ss -tlnp | grep sshd

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

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

1. Держите открытую текущую SSH-сессию и не закрывайте её до проверки.
2. Перед применением всегда проверяйте синтаксис.
3. Проверяйте изменения вторым подключением (параллельно), а не в той же сессии.

Проверка синтаксиса:

sudo sshd -t

Перечитать конфиг без жёсткого разрыва сессий обычно можно через reload (команда зависит от системы):

sudo systemctl reload sshd

Если вы уже «заперли» себя и единственный доступ был по SSH, не экспериментируйте вслепую с портами и паролями. Сначала восстановите доступ через консоль/панель, и только затем ужесточайте настройки.

Короткий чек-лист: что проверить в первую очередь

• На клиенте: ssh -vvv, какой ключ предлагается, при необходимости -i; проверьте ssh-agent.
• На сервере: ключ лежит в ~/.ssh/authorized_keys именно того пользователя, под которым вы входите.
• Права и владельцы: ~/.ssh = 700, authorized_keys = 600, владельцы корректные; home без групповой/общей записи.
• sshd_config: PubkeyAuthentication yes, правильный AuthorizedKeysFile, нет подмены в Match.
• Логи sshd: они чаще всего прямо пишут причину отказа.

Мини-справка: типовой рабочий набор параметров sshd_config

Это не «универсальная истина», а ориентир для большинства серверов, где вход выполняется по ключам, а пароль отключён:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

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

Если вы планируете переносить проекты или менять схему доступа (например, переехать с shared на сервер с полным контролем), пригодится пошаговая инструкция: как перенести сайт с виртуального хостинга на VDS.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Итог

Permission denied (publickey) — это не «сломался SSH», а сигнал: сервер не смог сопоставить ваш публичный ключ с тем, что разрешено для указанного пользователя, или отверг его из-за политики/прав. Начинайте с ssh -vvv, затем проверьте authorized_keys и права на .ssh, после — sshd_config (включая Match) и логи. Такой порядок почти всегда приводит к причине за считанные минуты.