Permission denied (publickey): почему SSH не принимает ключ и как это исправить

Permission denied (publickey) означает, что SSH-соединение установлено, а аутентификация не прошла: сервер не принял ваш ключ, а вход по паролю на нём выключен, поэтому запроса пароля вы и не видите. Причина почти всегда одна из четырёх: клиент предлагает не тот ключ, вы входите не под тем пользователем, у файлов на сервере неверные права или ключ так и не попал в authorized_keys.

OpenSSH свои сообщения не переводит, поэтому текст ошибки одинаков везде: в терминале Linux и macOS, в PowerShell на русской Windows и в логах сервера с любой локалью.

Что означает список в скобках

В скобках сервер перечисляет способы входа, которые он готов принять от этого пользователя. Это подсказка, где искать:

Permission denied (publickey).
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Permission denied (publickey,password).

(publickey) — сервер пускает только по ключу. Вариант с gssapi-keyex,gssapi-with-mic типичен для Rocky Linux, AlmaLinux, CentOS и RHEL, где в конфиге sshd включён GSSAPI (Kerberos). Без Kerberos это то же самое, что просто publickey: пароля в списке нет, и чинить нужно ключ. Если в списке есть password, сервер принимает и пароль, а значит, не подошёл ни ключ, ни введённый пароль.

Начните с подробного вывода

Флаг -v показывает, какие ключи предложил клиент и что ответил сервер. Прочитайте его, прежде чем что-то менять:

ssh -v user@host
# ищите строки вида:
#   Offering public key: /home/you/.ssh/id_ed25519
#   Authentications that can continue: publickey

1. Вы входите под тем пользователем?

Ключ в authorized_keys пользователя root ничего не даёт при ssh ubuntu@host. В облачных образах есть пользователь по умолчанию — ubuntu, debian, admin, ec2-user, rocky, — и ключ обычно устанавливается ему, а не root.

2. Клиент предлагает нужный ключ?

Если в выводе -v вашего ключа нет среди предложенных, укажите его явно:

ssh -i ~/.ssh/id_ed25519 user@host

Чтобы больше не гадать, пропишите его в ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Если перед ошибкой клиент пишет WARNING: UNPROTECTED PRIVATE KEY FILE! и This private key will be ignored., закрытый ключ на вашем компьютере доступен другим пользователям, и ssh его не использует. В Linux и macOS это исправляет chmod 600 ~/.ssh/id_ed25519. Встроенный клиент OpenSSH в Windows проверяет права так же, но chmod там нет: доступ к файлу ключа в C:\Users\имя\.ssh нужно оставить только своей учётной записи.

3. Права на файлы на сервере

sshd молча отвергает ключ, если файлы доступны на запись группе или всем. После ручного копирования это самая частая причина. Исправьте права из уже открытого SSH-сеанса или из консоли:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

4. Ключ действительно установлен?

Не вставляйте ключ вручную, а скопируйте его как следует — ssh-copy-id допишет его с правильными правами:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

# то же вручную, пока вход по паролю ещё включён:
cat ~/.ssh/id_ed25519.pub | ssh user@host \
  "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Убедитесь, что вставляете файл .pub, а не закрытый ключ, и что это одна цельная строка, которая начинается с ssh-ed25519 или ssh-rsa.

Проверьте конфиг и логи сервера

# что записал демон во время вашей попытки
# (на Rocky, Alma и CentOS юнит называется sshd)
sudo journalctl -u ssh -n 30

# включён ли вообще вход по ключу
sudo grep -Ei 'PubkeyAuthentication|AuthorizedKeysFile' /etc/ssh/sshd_config

Строка Authentication refused: bad ownership or modes в логе указывает прямо на права из пункта 3.

git@github.com: Permission denied (publickey)

Та же ошибка при git clone, git pull или git push по SSH, обычно с припиской fatal: Could not read from remote repository. (git с русской локалью пишет fatal: Не удалось прочитать из внешнего репозитория.), означает, что GitHub (или GitLab) не принял ни один из предложенных ключей. Пользователь здесь всегда git, а не ваш логин, так что пункт 1 отпадает. Проверьте подключение без репозитория:

ssh -T git@github.com
# если ключ принят, GitHub отвечает:
# Hi USERNAME! You've successfully authenticated, but GitHub does not provide shell access.

Если снова Permission denied (publickey), добавьте содержимое своего .pub-файла в аккаунт (на GitHub — Settings → SSH and GPG keys). Если ключей у вас несколько, привяжите нужный к хосту в ~/.ssh/config блоком Host github.com с теми же IdentityFile и IdentitiesOnly yes, что и выше.

PuTTY: Server refused our key

PuTTY пишет о том же по-своему. Server refused our key значит, что ключ был предложен и сервер его отверг; причины те же, что в пунктах 1–4. No supported authentication methods available (server sent: publickey) значит, что у PuTTY закончились способы входа, а сервер принимает только ключ: либо ключ уже был отвергнут, либо закрытый ключ вообще не указан в настройках сессии (в текущих версиях это Connection → SSH → Auth → Credentials).

PuTTY читает ключи только в своём формате .ppk; ключ OpenSSH сначала импортируйте в PuTTYgen (Conversions → Import key). В authorized_keys кладите строку из поля «Public key for pasting into OpenSSH authorized_keys file», а не файл, сохранённый кнопкой Save public key: его многострочный формат sshd не понимает.

Если на сервер можно войти только по ключу, а консоли нет, рано или поздно вы потеряете к нему доступ. На VPS от VMHeaven в личном кабинете можно задать новый пароль root и SSH-ключ, а VNC-консоль в браузере позволяет поправить authorized_keys без переустановки — такой запасной вход стоит иметь до того, как вы отключите пароли.

Частые вопросы