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

Что сделать прямо сейчас

1. Проверьте имя пользователя и IP в команде: ключ, добавленный для root, не пустит под другим именем, и наоборот.
2. Укажите ключ явно: ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@ВАШ_IP.
3. Убедитесь, что открытый ключ лежит на сервере, — добавьте его через панель провайдера или через консоль.
4. Если не помогло, посмотрите журнал на сервере и подробный отчёт ssh -v.

Каждый пункт разобран ниже по шагам. Если ключ точно лежит на сервере, начните с раздела «Шаг 4. Проверьте права на сервере»: сервер не принимает ключ, если права на папки слишком широкие.

Вместо ВАШ_IP подставьте адрес своего сервера из панели провайдера. В примерах вывода стоит адрес 203.0.113.10 — у вас будет свой IP.

Что значит эта ошибка

Полностью сообщение выглядит так:

ivan@203.0.113.10: Permission denied (publickey).

Перед двоеточием — пользователь и адрес, к которым вы подключались. В скобках сервер перечисляет способы входа, которые он принимает. Здесь там только publickey — вход по ключу. Пароль такой сервер не принимает, поэтому ssh его и не спрашивает.

Ошибка значит: ваш компьютер предложил серверу ключи, и ни один не подошёл. Возможные причины:

• вы входите не под тем пользователем или не на тот сервер;
• ssh предлагает не тот ключ, а нужный не находит;
• открытого ключа нет на сервере в файле authorized_keys;
• ключ на месте, но у папок или файла на сервере слишком широкие права, и сервер ключ не принимает.

Если в скобках два слова — (publickey,password), — сервер принимает и пароль. Тогда смотрите страницу Permission denied, please try again.

Шаг 1. Проверьте пользователя и адрес

Ключ привязан к пользователю на сервере. Ключ, добавленный для root, не пустит под ivan, и наоборот. Имя, под которым вы входите, стоит в команде перед знаком @:

ssh root@ВАШ_IP

Сверьте IP с панелью провайдера. Если в адресе опечатка, вы стучитесь на чужой сервер, и ваш ключ там не подойдёт. Подсказка: если ssh вдруг спросил, доверять ли серверу, хотя вы уже подключались к нему с этого компьютера, — возможно, адрес не тот.

Если вы входите по короткому имени из файла config, например ssh myvps, проверьте в этом файле строки HostName и User — как устроен файл config.

Шаг 2. Укажите ключ явно

Без подсказки ssh пробует ключи со стандартными именами из папки .ssh — например, id_ed25519, id_rsa, id_ecdsa — и ключи, которые держит ssh-agent. Если ваш ключ называется иначе или лежит в другой папке, ssh его не найдёт. Укажите файл сами. На Mac и Linux:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@ВАШ_IP

Команды для Windows ниже — для «Командной строки»: нажмите Win+R, напечатайте cmd и нажмите Enter (подробнее). Если строка в окне начинается с PS, это PowerShell: напечатайте cmd, нажмите Enter и продолжайте в том же окне.

ssh -i "%USERPROFILE%\.ssh\id_ed25519" -o IdentitiesOnly=yes root@ВАШ_IP

Флаг -i задаёт файл ключа. Параметр IdentitiesOnly=yes запрещает ssh пробовать другие ключи, в том числе из ssh-agent. Без него ssh может перебрать столько ключей, что сервер оборвёт подключение раньше, чем дойдёт очередь до нужного, — об этом страница Too many authentication failures.

После -i указывают закрытый ключ — файл без .pub на конце. Файл с .pub — открытый ключ, его кладут на сервер. Если указать .pub, ssh может выдать предупреждение о правах на файл ключа — см. UNPROTECTED PRIVATE KEY FILE.

Если с -i вход заработал, пропишите ключ в файле config, чтобы не набирать его каждый раз: строки IdentityFile и IdentitiesOnly yes (пример файла).

Шаг 3. Проверьте, что ключ лежит на сервере

Открытый ключ должен лежать на сервере в файле .ssh/authorized_keys — в домашней папке того пользователя, под которым вы входите. Сначала выведите свой открытый ключ на экран. На Mac и Linux:

cat ~/.ssh/id_ed25519.pub

В «Командной строке» Windows:

type "%USERPROFILE%\.ssh\id_ed25519.pub"

Это одна длинная строка: в начале — тип ключа, например ssh-ed25519, дальше — длинный набор букв и цифр, в конце — подпись вроде anna@MacBook-Air. Копируйте её целиком.

Проще всего добавить ключ через панель провайдера или командой — так, как описано в шаге 2 инструкции по SSH. Команда сработает, только если сервер ещё пускает вас по паролю. Если не пускает никак, зайдите через консоль в панели провайдера и добавьте ключ вручную. Команды ниже — для пользователя ivan. Если входите под root, вместо /home/ivan/.ssh пишите /root/.ssh, а последнюю команду с chown пропустите.

sudo mkdir -p /home/ivan/.ssh
sudo nano /home/ivan/.ssh/authorized_keys

Откроется редактор nano. Перейдите стрелками в конец файла и вставьте строку ключа — одной строкой, без переносов. Если в файле уже есть ключи, новый должен начинаться с новой строки. Сохраните файл: Ctrl+O, затем Enter, и выйдите: Ctrl+X. Подробнее о редакторе — в разделе про nano. Как вставлять текст в консоль вашего провайдера, сказано в разделе про консоль по ссылке выше.

Затем задайте права и владельца:

sudo chmod 700 /home/ivan/.ssh
sudo chmod 600 /home/ivan/.ssh/authorized_keys
sudo chown -R ivan:ivan /home/ivan/.ssh

Шаг 4. Проверьте права на сервере

Сервер SSH проверяет права на файл с ключами и на папки над ним: за это отвечает настройка StrictModes, по умолчанию она включена. Если домашнюю папку, папку .ssh или файл authorized_keys может менять кто-то, кроме хозяина, сервер ключ не примет, даже если он записан верно.

Посмотрите права через консоль или под другим рабочим входом:

sudo ls -ld /home/ivan /home/ivan/.ssh /home/ivan/.ssh/authorized_keys

В каждой строке важны два места. Первые десять знаков — права: первый знак — тип (d — папка, дефис — файл), дальше три тройки букв — для владельца, для группы и для всех остальных. Буква w — право на запись — должна стоять только в первой тройке. Третья колонка — владелец: там должно быть ivan.

После команд из шага 3 у папки .ssh права будут drwx------, у файла authorized_keys — -rw-------. Если буква w есть во второй или третьей тройке или владелец другой, исправьте:

sudo chmod go-w /home/ivan
sudo chmod 700 /home/ivan/.ssh
sudo chmod 600 /home/ivan/.ssh/authorized_keys
sudo chown -R ivan:ivan /home/ivan/.ssh

Первая команда только убирает право записи у группы и остальных с домашней папки, другие права она не трогает. Для root команды те же, но с /root вместо /home/ivan, а команда chown не нужна.

Шаг 5. Посмотрите журнал сервера

Если ключ на месте и права верные, причину отказа подскажет журнал SSH на сервере. Попробуйте подключиться ещё раз, а затем выполните в консоли:

sudo journalctl -u ssh -n 50

Команда покажет последние 50 строк журнала, свежие — внизу. Ищите строки с именем пользователя, под которым входили:

Вместо 198.51.100.7 в журнале будет IP вашего компьютера, а номер порта — другой.

Если файла authorized_keys нет вовсе, журнал на обычном уровне об этом промолчит. Строки Failed publickey тоже появляются не сразу, а только после нескольких неудачных попыток в одном подключении. Поэтому, если в журнале пусто, вернитесь к шагу 3.

Что показывает ssh -v

Если причина всё ещё не ясна, запустите подключение с подробным отчётом:

ssh -v -i ~/.ssh/id_ed25519 root@ВАШ_IP

Отчёт длинный, его строки начинаются с debug1. Найдите в нём такие строки:

Если строки Offering public key с вашим ключом в отчёте нет совсем, ssh его не нашёл — вернитесь к шагу 2.

Как проверить

Подключитесь снова. Если всё исправлено, пароль сервера не спросят, и вы увидите приглашение сервера. Если вы задали ключу кодовую фразу, ssh спросит её — это фраза от ключа, а не пароль сервера. В отчёте ssh -v успешный вход по ключу выглядит так:

Authenticated to 203.0.113.10 ([203.0.113.10]:22) using "publickey".

Похожие ошибки

Источники

• man ssh — параметры -i и -v.
• man ssh_config — IdentityFile и IdentitiesOnly.
• man sshd_config — AuthorizedKeysFile и StrictModes.
• Исходный код OpenSSH — тексты сообщений клиента и сервера.
• Ubuntu Server: сервер OpenSSH — сервер SSH в Ubuntu.
• man journalctl — параметры -u и -n.

Сверено 9 октября 2026 года.

Что почитать дальше

• Как подключиться к VPS по SSH — вход по ключу с нуля и консоль в панели провайдера.
• Как настроить VPS с нуля — как завести обычного пользователя вместо root.
• Permission denied, please try again — если сервер спрашивает пароль и не принимает его.
• Too many authentication failures — если ключей слишком много.