SSH LinuxmacOSWindows Permission denied (publickey)Too many authentication failures

SSH: «Permission denied (publickey)» — как исправить

  • Обновлено
  • Чтение ≈ 4 минуты
  • Нужны права администратора

Краткий ответ

Permission denied (publickey) означает, что сервер SSH отверг все предложенные клиентом ключи, а другие способы входа (например, пароль) недоступны. Причины: ключ не добавлен в authorized_keys, неверное имя пользователя, слишком открытые права на ~/.ssh и домашний каталог, запрет по ключам в sshd_config или клиент предлагает не тот ключ. Запустите ssh -v и сравните его вывод с журналом сервера — так причина находится за пару минут.

В этой статье
  1. Что означает ошибка
  2. Причины и решения
  3. Алгоритм диагностики
  4. Шаг 1 и 3. Подробный вывод и явный ключ
  5. Шаг 4. Добавление ключа и права на сервере
  6. Шаг 5. Настройки и журнал sshd
  7. Как проверить результат
  8. Если не помогло

#Что означает ошибка

Permission denied (publickey)
user@203.0.113.10: Permission denied (publickey).
По-русскиОтказано в доступе: ни один предложенный открытый ключ сервером не принят.

При входе по ключу клиент по очереди предлагает серверу свои ключи, а сервер ищет подходящий открытый ключ в файле ~/.ssh/authorized_keys нужного пользователя. Если совпадения нет или сервер не может доверять файлу, вход отклоняется. В скобках — перечень методов, которые сервер ещё готов принять: (publickey) — только ключи, (publickey,password) — ключи и пароль.

#Причины и решения

Возможная причинаКак узнатьЧто делать
Ключ не добавлен на сервер или это другой ключОткрытый ключ, соответствующий вашему закрытому, отсутствует в authorized_keys — либо в файле лежит не тот ключ.В ssh -v ключ предлагается («Offering public key»), но принят не будет; на сервере в журнале нет «Accepted publickey».Добавьте правильный открытый ключ на сервер (шаг 4).
Неверные права на файлы и каталогиСервер игнорирует authorized_keys, если каталог ~/.ssh или домашний каталог доступны на запись группе или всем (по умолчанию включён StrictModes).В журнале сервера есть запись Authentication refused: bad ownership or modes.Исправьте права: ~/.ssh — 700, authorized_keys — 600, домашний каталог не должен быть открыт на запись другим.
Неверное имя пользователяВы входите как root, а ключ добавлен для ubuntu, admin или другого пользователя.Другая учётная запись принимает тот же ключ; у облачных образов имя часто задано провайдером.Подключайтесь тем пользователем, для которого добавлен ключ: ssh пользователь@хост.
Сервер запрещает вход по ключам или для этого пользователяВ sshd_config отключена PubkeyAuthentication, ограничения AllowUsers/AllowGroups либо запрещён вход root.В журнале видно отклонение пользователя; настройки изменились недавно.Проверьте sshd_config (шаг 5), после правок перезагрузите службу sshd.
Клиент не предлагает нужный ключКлюч лежит не в стандартном месте, не добавлен в агент, либо у вас так много ключей, что сервер обрывает попытки.В ssh -v нет строки с вашим ключом или сообщение Too many authentication failures.Явно укажите ключ: -i путь и -o IdentitiesOnly=yes (шаг 3).

#Алгоритм диагностики

  1. Запустите подключение с подробным выводомНа компьютере откройте терминал и выполните ssh -vvv пользователь@сервер с реальным именем; найдите строки Offering public key, Server accepts key или Permission denied. Не публикуйте весь подробный вывод без проверки: в нём могут быть имена внутренних серверов и учётных записей.
  2. Проверьте имя пользователя и адресУточните у администратора, какое имя пользователя и порт должны использоваться, поскольку образы Ubuntu, Debian и облачные платформы часто имеют разные начальные учётные записи. Проверьте, что подключаетесь именно к нужному IP/DNS, а не к старой машине после смены хостинга.
  3. Укажите ключ явноЗатем выполните ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 пользователь@сервер; замените путь на фактический приватный ключ. Если появляется No such file, найдите ключ на своём компьютере, если UNPROTECTED PRIVATE KEY FILE — исправьте его локальные права. Не передавайте приватный ключ на сервер.
  4. Проверьте файлы на сервереЧерез консоль провайдера проверьте на сервере соответствующий публичный ключ в ~/.ssh/authorized_keys, владельца домашнего каталога и права .ssh/authorized_keys. Команда ssh-copy-id работает только если уже есть разрешённый способ входа; при полном отказе в SSH используйте консоль и добавление ключа через панель провайдера.
  5. Проверьте настройки sshd и журналПроверьте настройки PubkeyAuthentication, AuthorizedKeysFile, блоки Match и запреты пользователей в выводе sshd -T, а также журналы journalctl -u ssh или /var/log/auth.log. После точечной правки выполните sshd -t и откройте новое подключение, не закрывая рабочую консоль. Не включайте парольную авторизацию всему Интернету как обход.

#Шаг 1 и 3. Подробный вывод и явный ключ

Linux · Терминал (Bash)Команда
Ищите строки «Offering public key» (ключ предложен) и «Authentications that can continue» (что разрешено серверу). Параметр IdentitiesOnly=yes запрещает отправлять другие ключи из агента.
ssh -v -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes пользователь@адрес-сервера

#Шаг 4. Добавление ключа и права на сервере

Linux · Терминал (Bash)Команда
Копирует открытый ключ в authorized_keys на сервере. Работает, пока доступен вход по паролю; если пароль запрещён, добавьте ключ через консоль провайдера.
ssh-copy-id -i ~/.ssh/id_ed25519.pub пользователь@адрес-сервера
Linux · Терминал (Bash)Команда
Выполняется на сервере от имени пользователя, под которым входите. Последняя команда показывает итоговые права для проверки.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

#Шаг 5. Настройки и журнал sshd

Linux · Терминал (Bash)КомандаНужен sudo
Показывает действующие настройки и последние записи журнала. В некоторых дистрибутивах служба называется sshd — тогда замените -u ssh на -u sshd.
sudo sshd -T | grep -Ei "pubkeyauthentication|allowusers|allowgroups|permitrootlogin|passwordauthentication"
sudo journalctl -u ssh -n 30 --no-pager

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

#Как проверить результат

  • Подключение проходит без запроса пароля; в журнале сервера есть Accepted publickey for ….
  • ssh -v показывает, что принят именно тот ключ, который вы ожидали.
  • Права на ~/.ssh и authorized_keys соответствуют рекомендованным.

#Если не помогло

Проверьте, не включён ли на сервере SELinux или AppArmor с ограничениями на домашние каталоги, и не лежит ли домашний каталог на сетевой файловой системе с особыми правами. Попробуйте сгенерировать новую пару ключей (ssh-keygen -t ed25519) и добавить её заново, а также убедитесь, что на сервере не истёк срок действия учётной записи.

Так эту ошибку тоже называют

SSH: Connection refused на порту 22 — причины и решение Проверьте, запущен ли sshd, и правила файрвола. Linux SSH Linux SSH: Permission denied (publickey) — права authorized_keys — причины и решение Проверьте владельца и права ~/.ssh и authorized_keys. Linux SSH Linux SSH: Connection timed out — нет ответа на порту 22 — причины и решение «ssh: connect to host … port 22: Connection timed out» значит, что пакеты до сервера не доходят: закрыт порт файрволом, неверный адрес, не запущен sshd или SSH работает … Linux SSH Linux SSH: Connection refused — соединение отклонено — причины и решение Ошибка ssh: connect to host port 22: Connection refused означает, что на сервере не слушает sshd или порт закрыт файрволом. Проверьте службу sshd, порт, ufw/firewalld, п… Linux SSH Linux SSH: Host key verification failed — REMOTE HOST IDENTIFICATION HAS CHANGED — причины и решение SSH предупреждает, что ключ сервера изменился. Ниже — причины и порядок действий от простого к сложному. Linux SSH Linux

Источники и обновления

Последнее обновление статьи: 1 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.