Permission denied (publickey).

Перед сообщением стоит `user@host:`. Список в скобках показывает методы, которые сервер ещё разрешает, например `(publickey,password)` или `(publickey,gssapi-keyex,gssapi-with-mic)`.

Что это означает

SSH-соединение установлено, и хост прошёл проверку, но сервер не принял ни одного из открытых ключей, предложенных клиентом, а аутентификация по открытому ключу — единственный метод, который он разрешает (список в скобках). Клиент никогда не узнаёт, почему ключ отклонён: причина есть только в журнале сервера. На GitHub, GitLab и Bitbucket то же сообщение означает, что ни один из ваших ключей не зарегистрирован в аккаунте с доступом к этому репозиторию (или как его ключ развёртывания).

Почему это происходит

• Нужный ключ не предлагается

  часто

  Ключа нет в агенте, он не лежит по пути по умолчанию (`~/.ssh/id_ed25519`, `id_ecdsa`, `id_rsa`) и не указан через `-i` или `IdentityFile`. Если в агенте много ключей, сервер может разорвать соединение (MaxAuthTries) раньше, чем очередь дойдёт до нужного.

• Ключа нет в authorized_keys этого пользователя

  часто

  Ключ установлен для другого пользователя или хоста, удалён при переустановке или (в случае Git-хостинга) добавлен не в тот аккаунт, у которого есть доступ к репозиторию.

• sshd игнорирует authorized_keys из-за прав доступа

  иногда

  При `StrictModes yes` (значение по умолчанию) sshd отказывается использовать файл, если домашний каталог, `~/.ssh` или `authorized_keys` доступны на запись группе или всем. В журнале сервера появляется «Authentication refused: bad ownership or modes».

• Алгоритм подписи ключа не принимается

  иногда

  Серверы OpenSSH 8.8+ отклоняют ключи RSA, которые старые клиенты и библиотеки используют с алгоритмом SHA-1 `ssh-rsa`; поддержку ключей DSA в OpenSSH 10 удалили полностью. Сервер записывает в журнал «not in PubkeyAcceptedAlgorithms».

• Неверное имя удалённого пользователя

  иногда

  `ssh server` входит под вашим локальным именем пользователя. Облачные образы ожидают `ubuntu`, `ec2-user`, `admin`; Git-хостинги всегда ожидают `git@`.

Как исправить

1. 1.

   Посмотрите, какие ключи предлагаются

   `ssh -v` выводит каждый ключ, предлагаемый клиентом, и то, принял ли его сервер; `ssh -G` показывает фактического пользователя и файлы ключей с учётом всей конфигурации.

   ssh -v deploy@server.example.com 2>&1 | grep -E "Offering|Server accepts|Authentications that can continue|send_pubkey_test"
   ssh-add -l                                  # keys the agent offers
   ssh -G deploy@server.example.com | grep -E "^(user|identityfile|identitiesonly) "

2. 2.

   Закрепите файл ключа за каждым хостом

   `IdentityFile` вместе с `IdentitiesOnly yes` предлагает ровно один ключ и избавляет от «Too many authentication failures», если в агенте много ключей.

   # ~/.ssh/config
   Host server.example.com
     User deploy
     IdentityFile ~/.ssh/deploy_ed25519
     IdentitiesOnly yes

3. 3.

   Исправьте настройки сервера и прочитайте его журнал

   Установите открытый ключ для нужного пользователя со строгими правами доступа и найдите в журнале sshd конкретную причину отказа.

   # On the server: install the key and fix modes (sshd ignores keys in group/world-writable paths)
   install -d -m 700 ~/.ssh && cat deploy_ed25519.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
   sudo journalctl -u ssh --since "10 min ago" | grep -E "Authentication refused|not in PubkeyAccepted|Failed publickey"

← Открыть всю базу ошибок подписей