Краткий ответ
Ошибка permission denied publickey означает, что сервер не принял ваш открытый ключ, хотя пароль может быть верным. Чаще всего виноваты неправильный ключ на клиенте, неверные права на ~/.ssh и authorized_keys или настройка в sshd_config. Проверьте их по порядку, и доступ вернется без переустановки.
Как проявляется проблема
- Вход по SSH завершается с сообщением Permission denied (publickey)
- Пароль не запрашивается или сервер сразу его отклоняет
- Тот же ключ работал вчера, а сегодня уже нет
- Вход работает с одного компьютера, а с другого нет
- После смены пользователя или переустановки сервера ключ отклоняется
Частые причины
Неправильный или отсутствующий закрытый ключ
SSH-клиент пытается войти с ключом, который сервер не знает, или ключ не загружен в агент. Проверьте, какой ключ на самом деле предлагается серверу.
Неверные права на .ssh и authorized_keys
Если домашний каталог, ~/.ssh или authorized_keys имеют слишком широкие права, sshd отклоняет их из соображений безопасности. Это самая частая причина после ручного копирования файлов.
Ключ не находится в authorized_keys для этого пользователя
Ключ добавлен не тому аккаунту, например root вместо deploy, или файл перезаписан вместо дополнения. В этом случае серверу не с чем сравнивать.
sshd_config не разрешает вход по ключу
Опции вроде PubkeyAuthentication, AuthorizedKeysFile или AllowUsers могут отключить ключ или пользователя. После изменения конфигурации службу нужно перезагрузить.
SELinux или домашний каталог с неверным контекстом
В системах с SELinux файл может иметь неверный контекст безопасности, даже если права верны. Обычно проблему решает restorecon.
Пошаговое решение
- 1
Прочитайте точное сообщение и пользователя
Запустите вход с
-v, чтобы увидеть подробности:ssh -v пользователь@сервер. В выводе ищите, какие ключи предлагает клиент и отклоняет ли сервер все. Проверьте также, что вы используете правильного пользователя и порт, так как ошибка часто возникает только для одного аккаунта. - 2
Проверьте, какой ключ использует клиент
На клиенте выполните
ssh-add -l, чтобы увидеть ключи в агенте. Если нужен другой ключ, укажите его явно:ssh -i ~/.ssh/id_ed25519 пользователь@сервер. В~/.ssh/configможно для хоста добавитьIdentityFileиIdentitiesOnly yes, чтобы клиент не предлагал неправильные ключи. - 3
Сравните отпечаток ключа с сервером
На клиенте вычислите отпечаток:
ssh-keygen -lf ~/.ssh/id_ed25519.pub. На сервере, если есть другой доступ, проверьтеssh-keygen -lf ~/.ssh/authorized_keys. Отпечатки должны совпасть; если нет, ключ не добавлен или добавлен не тому пользователю. - 4
Исправьте права на сервере
Войдите через консоль или другой аккаунт и выполните (замените
пользовательреальным именем, а/home/пользовательреальным путем к домашнему каталогу; если вы не root, добавьтеsudo):chmod 700 /home/пользователь/.ssh,chmod 600 /home/пользователь/.ssh/authorized_keys,chmod go-w /home/пользовательиchown -R пользователь:пользователь /home/пользователь/.ssh. Владельцем.sshиauthorized_keysдолжен быть этот пользователь. Если не уверены в текущих правах, сначала запишите их с помощьюstat -c '%a %U:%G' /home/пользователь /home/пользователь/.ssh /home/пользователь/.ssh/authorized_keys. Это решает большинство случаев после ручного копирования. - 5
Добавьте открытый ключ в нужное место
Содержимое файла
id_ed25519.pubдобавьте в/home/пользователь/.ssh/authorized_keysэтого пользователя, в новую строку, не удаляя существующие. Если используетеssh-copy-id, проверьте, что целевой пользователь указан верно. После изменения снова проверьте права из предыдущего шага. - 6
Проверьте sshd_config
В
/etc/ssh/sshd_config(или файле вsshd_config.d) проверьтеPubkeyAuthentication yes,AuthorizedKeysFile .ssh/authorized_keysи что вас не блокируетAllowUsersилиDenyUsers. Перед изменением сделайте копию файла. После изменения выполнитеsudo sshd -tдля проверки синтаксиса. - 7
Перезагрузите службу SSH
Если конфигурация верна, примените ее с помощью
sudo systemctl reload sshd(в Debian/Ubuntu:sudo systemctl reload ssh). Reload безопаснее перезапуска, так как не прерывает существующие сессии. Затем попробуйте войти из нового терминала, не закрывая старый. - 8
Исправьте контекст SELinux, если он включен
В системах с SELinux выполните
sudo restorecon -Rv /home/пользователь/.ssh. Проверка статуса:getenforce. Если проблема осталась, в журнале/var/log/secureили/var/log/auth.logищите сообщения об отклонении ключа. Не отключайте SELinux навсегда.
Если ничего не помогает: доступ через консоль и резервный аккаунт
Когда ключ не проходит даже после всех проверок, используйте консоль провайдера или KVM-доступ к серверу и войдите по паролю или через режим восстановления. Тогда из /var/log/auth.log или /var/log/secure прочитайте точную причину отказа, так как sshd пишет там, в чем проблема: в правах, владельце или конфигурации. Хорошая практика всегда иметь второй административный аккаунт с ключом и не отключать PasswordAuthentication, пока не убедитесь, что ключ работает. Если сервер в облаке, проверьте также, привязан ли открытый ключ к экземпляру в панели управления провайдера, так как при пересоздании экземпляра он иногда теряется.
Как избежать повторения
- Держите резервный административный аккаунт с действующим ключом
- После каждого изменения sshd_config проверяйте синтаксис с помощью `sudo sshd -t` перед reload
- Используйте `ssh-copy-id` и не копируйте файлы вручную без настройки прав
- Периодически проверяйте, что ключ в агенте совпадает с ключом на сервере
Когда лучше обратиться к специалисту
Если у вас нет консоли, резервного аккаунта и действующего ключа, а сервер production, лучше обратиться в IT-поддержку, чем экспериментировать с sshd_config и рисковать полной потерей доступа.
Обслуживание ИТ-инфраструктуры · Серверы, сети, резервное копирование, безопасность и helpdeskЧастые вопросы
Связана ли ошибка publickey с паролем?
Нет. Сообщение Permission denied (publickey) означает, что сервер отклонил ключ, а не пароль. Пароль вообще не проверяется, если вход по ключу является единственным разрешенным методом.
Почему ключ работает для root, а для обычного пользователя нет?
Потому что authorized_keys читается из домашнего каталога вошедшего пользователя. Ключ, добавленный в домашний каталог root, не действует для другого аккаунта, а права и владелец проверяются отдельно для каждого пользователя.
Можно ли вернуть вход по паролю, пока я решаю проблему с ключом?
Можно, если у вас есть доступ к консоли и установлен пароль. Временно включите `PasswordAuthentication yes` в sshd_config, выполните reload и сразу после решения проблемы с ключом верните эту опцию на `no`. Это рискованно с точки зрения безопасности, поэтому используйте надежный пароль и по возможности ограничьте доступ с помощью firewall.