SSH: Permission denied (publickey) — права authorized_keys

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

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

Для диагностики запустите клиент в подробном режиме: ssh -vvv user@host. По выводу видно, какие ключи пробовались и почему сервер отклонил их.

Проверьте владельца и права ~/.ssh и authorized_keys.

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

#Пошаговое решение

1. Запустите подключение с подробным выводомНа компьютере откройте терминал и выполните ssh -vvv -i ~/.ssh/id_ed25519 пользователь@хост, заменив ключ и адрес. В выводе найдите Offering public key и окончательное Permission denied (publickey). Приватный ключ не показывайте в журнале; если соединение даже не устанавливается, сначала исследуйте сеть и порт.
2. Проверьте имя пользователя и адресПроверьте реальное имя учётной записи и адрес сервера в панели провайдера или у администратора; некоторые образы запрещают вход root и используют стандартного системного пользователя. Сверьте порт SSH, если он изменён; сервер и имя должны соответствовать установленному публичному ключу.
3. Укажите ключ явноДля исключения перебора ключей повторите ssh -o IdentitiesOnly=yes -i /путь/к/ключу пользователь@хост. Если клиент сообщает, что файл не найден или права слишком открыты, исправьте путь/chmod 600 на локальном приватном ключе. Не копируйте его содержимое в authorized_keys: там должен быть публичный ключ.
4. Проверьте файлы на сервереЧерез консоль хостинга войдите на сервер независимо от SSH, откройте ~/.ssh/authorized_keys нужного пользователя и проверьте, что там одной строкой находится соответствующий публичный ключ. Выполните ls -ld ~ ~/.ssh ~/.ssh/authorized_keys; скорректируйте владельца и права для конкретной учётной записи после проверки, обычно 700 для .ssh и 600 для authorized_keys.
5. Проверьте настройки sshd и журналНа сервере выполните sudo sshd -T (в некоторых системах sshd -T -C user=...,host=...,addr=...) и проверьте PubkeyAuthentication, AuthorizedKeysFile, Match-блоки и AllowUsers; журнал службы ищите через journalctl -u ssh или sshd. Прежде чем менять конфигурацию, проверьте sshd -t и сохраняйте консольную сессию для отката.

#Ключ и пользователь

Убедитесь, что публичный ключ (id_ed25519.pub) добавлен в ~/.ssh/authorized_keys того пользователя, под которым вы входите. Проверьте имя: на Ubuntu это обычно ubuntu, на Debian — debian или admin, на Amazon Linux — ec2-user. Копируйте ключ командой ssh-copy-id, а не вручную, чтобы избежать лишних переводов строк.

#Права на файлы

sshd отклоняет ключи, если права слишком открыты: каталог ~/.ssh должен иметь 700, файл authorized_keys — 600, закрытый ключ на клиенте — 600. Домашний каталог не должен быть доступен на запись для всех. Владельцем должен быть сам пользователь.

#Клиент не использует нужный ключ

Укажите ключ явно: ssh -i ~/.ssh/id_ed25519 user@host. Если у вас много ключей, агент может предложить их слишком много и сервер закроет соединение (Too many authentication failures): добавьте IdentitiesOnly yes в ~/.ssh/config. На Windows проверьте, что ssh-agent запущен и ключ добавлен командой ssh-add.

#Настройки сервера

Проверьте /etc/ssh/sshd_config: PubkeyAuthentication yes, AllowUsers, AuthorizedKeysFile. Журнал /var/log/auth.log (или journalctl -u ssh) содержит точную причину отказа. После изменений проверьте конфигурацию sshd -t и перезапустите службу.