termalPermission denied (publickey) — самая частая ошибка SSH на свете, и сообщение не делает вам никаких одолжений. Оно не означает «ваш ключ неправильный». Оно означает: сервер отверг все методы аутентификации, которые вы предложили, а публичный ключ был единственным методом, который он вообще готов был обсуждать. В скобках — список методов, которые сервер оставил открытыми: (publickey) значит, что парольная аутентификация выключена, поэтому должен сработать ключ, а ни один из ваших не сработал.
Список бывает и длиннее, и его стоит читать. Permission denied (publickey,password) означает, что сервер ещё принял бы и пароль — так что если вы собирались его ввести, а запроса так и не дождались, ваш клиент сдался на ключах, а должен был откатиться назад; принудите запрос через -o PubkeyAuthentication=no, чтобы проверить. Permission denied (publickey,keyboard-interactive) — та же идея с интерактивным методом (часто это запрос PAM или 2FA), всё ещё доступным. Что бы ни стояло в скобках — это полный набор дверей, которые сервер оставил открытыми; если ожидаемой вами там нет, сервер и не собирался её принимать.
Сеть широка: эту ошибку даёт неправильное имя пользователя. А ещё — ключ, который клиент так и не предложил, ключ, который сервер так и не получил, проблема с правами, которую sshd молча отказывается прощать, и метка SELinux, о которой вы никогда не слышали. Исправление системное, а не наугад — вот цикл, а затем виновники в порядке того, как часто они на самом деле оказываются ответом. (Пушите в GitHub или GitLab? Это другой чек-лист — SSH-ключ для GitHub/GitLab не работает.)
Цикл диагностики: читайте, что пробовал клиент
Запустите падающее подключение с максимальной детализацией (а если стена вывода выглядит шумом, как читать ssh -vvv (на английском) расшифровывает строки, которые важны):
ssh -vvv user@hostТри вещи, которые нужно найти в выводе:
Authentications that can continue: publickey— список методов сервера. Еслиpasswordотсутствует, пароль никогда не спросят; должен сработать ключ.Offering public key: /home/you/.ssh/id_ed25519— каждый ключ, который попробовал клиент. Если ключа, который вы имели в виду, в этом списке нет, проблема на стороне клиента (виновник 2). А если есть —- что пришло в ответ.
Server accepts key, за которым идёт обмен подписью, означает, что ключ подошёл, а что-то сломалось позже (редкость). Обычная же картина — предложение, за которым сразу идёт следующий ключ илиPermission denied: сервер взглянул на ключ и пожал плечами, а это указывает на серверную сторону (виновники 3–8).
Если у вас есть любой другой путь на машину (веб-консоль провайдера, другой пользователь, другой администратор), лог сервера называет настоящую причину напрямую:
sudo journalctl -u sshd -f # systemd distros
sudo tail -f /var/log/auth.log # Debian/Ubuntu
sudo tail -f /var/log/secure # RHEL/Alma/RockyСтроки вроде Authentication refused: bad ownership or modes for directory /home/deploy ставят точку в расследовании сразу.
Виновник 1: не тот пользователь
Самая частая причина, особенно на облачных образах (это первая стена первого входа на EC2 или VPS (на английском)), потому что пользователь для входа — не тот, что вы бы предположили: ubuntu в образах Ubuntu, ec2-user в Amazon Linux, admin в Debian AMI, root на большинстве «голых» VPS, azureuser в умолчаниях Azure. Правильный ключ с неправильным именем пользователя даёт ровно эту ошибку — сервер проверяет ~wronguser/.ssh/authorized_keys, ничего не находит, отказывает.
Прежде чем трогать что-то ещё, уточните пользователя, которого указывает документация вашего образа, и закрепите его в ~/.ssh/config, чтобы больше не перенабирать (гайд по ssh_config (на английском) разбирает этот приём):
Host web1
HostName 203.0.113.10
User ubuntuВиновник 2: ваш ключ так и не был предложен
Если ssh -vvv не показывает ваш ключ в строке Offering public key, клиент о нём не знает. Укажите на него явно:
ssh -i ~/.ssh/id_ed25519 user@hostЕсли сработало — закрепите это через IdentityFile в блоке конфигурации выше. Две смежные ловушки: агент, набитый множеством ключей, может упереться в лимит попыток сервера, не добравшись до нужного (Too many authentication failures — лечится IdentitiesOnly yes), а ключ с парольной фразой, из ввода которой вы вышли, молча пропускается. Проверьте, что агент на самом деле держит:
ssh-add -lВ Windows этот список может выглядеть пустым, даже если вы только что загрузили ключ, — Git Bash, служба OpenSSH и WSL запускают каждый свой агент, а ssh-add -l отвечает только за тот ssh, которым вы на самом деле пользуетесь; ssh-agent в Windows распутывает все три.
Виновник 3: публичного ключа нет на сервере
Публичная половина должна быть одной строкой в ~user/.ssh/authorized_keys — для того самого пользователя, в домашнем каталоге того самого пользователя. Надёжный способ положить её туда (для копирования использует парольную аутентификацию или уже имеющийся ключ):
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@hostДелаете вручную — скажем, через консоль провайдера — дописывайте одну строку и никогда не перезаписывайте файл:
mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys
# paste the one line from id_ed25519.pub, Enter, Ctrl-DКлассические промахи: ключ попал в файл root, а вы входите как deploy; строку перенёс редактор, и теперь это две строки; вы вставили приватный ключ (файл начинается с ssh-ed25519 AAAA… — если вы видите -----BEGIN, это не та половина).
Виновник 4: права и владелец
StrictModes в sshd (включён по умолчанию) отказывается учитывать authorized_keys, если путь к нему доступен на запись кому-то, кроме владельца. Это классическое «я скопировал ключ, а он всё равно не работает». Полное исправление, выполнить от имени целевого пользователя:
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.sshСтрока с домашним каталогом важна, и про неё забывают: /home/deploy, доступный на запись группе, проваливает проверку так же надёжно, как и файл ключа, читаемый всеми. Строка bad ownership or modes в логе сервера точно говорит, к какому каталогу у него претензии.
Виновник 5: не тот формат ключа или парольная фраза
OpenSSH не умеет читать файлы .ppk от PuTTY — если направить на такой -i, в подробном выводе будет invalid format. Экспортируйте ключ в формате OpenSSH из PuTTYgen (Conversions → Export OpenSSH key) или сгенерируйте свежий современный ключ и заведите его (Ed25519 почти во всех случаях (на английском)). Если вы на Windows и всё ещё живёте в PuTTYgen, то SSH-клиент для Windows, который импортирует сессии PuTTY и работает с ключами OpenSSH напрямую, вообще снимает этот шаг конвертации. Чтобы убедиться, что файл приватного ключа читается, а парольная фраза — та, что вы думаете, попросите его напечатать свою публичную половину:
ssh-keygen -y -f ~/.ssh/id_ed25519Если он напечатал ключ, значит файл и парольная фраза в порядке — и можно сверить вывод со строкой в authorized_keys, чтобы убедиться, что это действительно один и тот же ключ.
Виновник 6: конфигурация сервера это запрещает
Встречается реже, но проверить дёшево, когда есть доступ к серверу. Спросите у sshd, с чем он на самом деле работает:
sudo sshd -T | grep -Ei 'pubkeyauthentication|authorizedkeysfile'PubkeyAuthentication должен быть yes (по умолчанию так, но скрипты закалки иногда это переключают), а AuthorizedKeysFile говорит, где ищет sshd — если кто-то направил его на /etc/ssh/authorized_keys/%u, ваш аккуратно уложенный ~/.ssh/authorized_keys игнорируется. После любого изменения в /etc/ssh/sshd_config:
sudo systemctl reload sshdВиновник 7: контексты SELinux (семейство RHEL)
На RHEL, Alma, Rocky, Fedora и им подобных ~/.ssh, созданный необычным путём — восстановлен из бэкапа, скопирован от root, сделан на смонтированном томе, — может нести неправильную метку SELinux, и sshd получает отказ в доступе на чтение к файлу с идеальными правами. Всё выше сходится, ошибка не уходит, а ls -Z ~/.ssh показывает что-то отличное от ssh_home_t. Одна команда чинит метки:
restorecon -R -v ~/.sshЕсли на машине семейства RHEL идеи кончились — выполните её всё равно: когда метки и так были правильными, вреда от неё нет.
Виновник 8: вход под root отключён
Современные умолчания ставят PermitRootLogin prohibit-password (только по ключу) или no (никогда). Если вы пробуете root@host, а ключ действительно лежит в /root/.ssh/authorized_keys, проверьте:
sudo sshd -T | grep -i permitrootloginПри no для root не сработает ни один способ входа — зайдите непривилегированным пользователем и sudo, к чему умолчание вас и так подталкивает.
Короткие ответы
Значит ли Permission denied (publickey), что мой ключ повреждён?
Почти никогда. Это значит, что сервер не принял ни один из предложенных вами методов — обычно не тот пользователь или не тот ключ, а не сломанный ключ. Убедитесь, что ключ читается, а парольная фраза верна, командой ssh-keygen -y -f ~/.ssh/id_ed25519.
В чём разница между (publickey) и (publickey,password)?
В скобках перечислены методы, которые сервер всё ещё разрешает. (publickey) — только ключи; (publickey,password) значит, что сработал бы и пароль, так что вас должны были спросить — а если не спросили, ваш клиент сдался, исчерпав ключи.
Вчера работало, сегодня нет — что изменилось?
Пересобранный сервер, сменённый ключ или агент, который сбросил ключ по таймауту. Сначала выполните ssh-add -l, чтобы увидеть, что загружено, затем проверьте, не переустановили ли машину (это заодно даёт host key verification failed (на английском)).
Сделайте так, чтобы это перестало случаться
Почти каждый виновник выше — это факт о конкретном хосте, который вам не следует выводить заново: какой пользователь, какой ключ, какой порт. Закрепите их в ~/.ssh/config — и этот класс ошибок по большей части исчезает, а для оставшихся ошибок шпаргалка-дешифратор разбирает ещё девять, которые вам встретятся.
Те же факты могут жить в клиенте, а не в dot-файле. Termalin хранит пользователя, порт и ключ вместе с сохранённым хостом, разблокирует ваши ключи один раз через встроенный агент (никакого молчаливого пропуска ключа из-за отменённой парольной фразы), проверяет личность сервера при первом подключении и показывает живой статус по каждому хосту — так что «а она вообще жива?» и «я тем ли ключом пользуюсь?» перестают быть шагами диагностики. Он также напрямую импортирует сессии PuTTY (на английском), что окончательно выводит из игры виновника 5.
Termalin — бесплатный кроссплатформенный SSH-клиент, который хранит пользователей, порты и ключи для каждого хоста вместе с самим хостом и проверяет серверы при первом подключении — скачайте его или прочитайте, как он безопасно обращается с ключами.