Как исправить ошибку SSH Permission denied (publickey)

Что на самом деле означает ошибка Permission denied (publickey)

Ошибка Permission denied (publickey) означает, что ваш клиент отправил один или несколько открытых ключей, но сервер не принял ни один из них. Сеть работает исправно, и sshd запущен: отказ происходит на последнем этапе аутентификации. Если сессия прерывается раньше, вы столкнулись с отказом в соединении или истечением времени ожидания, что требует иной диагностики и других тестов. Исправление ошибки не должно быть догадкой, так как ssh -v точно указывает, какая из пяти причин привела к сбою.

Слова в скобках — это методы аутентификации, которые сервер готов принять. Permission denied (publickey) само по себе означает, что вход по паролю на сервере отключен, поэтому использовать пароль в качестве альтернативы невозможно. Permission denied (publickey,password) означает, что вход по паролю был предложен, но вы не прошли аутентификацию и этим способом.

Одно сообщение охватывает пять различных неисправностей, и оно намеренно сформулировано расплывчато. Сервер, который отвечал бы «пользователь не найден» или «ключ не установлен», помог бы злоумышленникам, сканирующим систему на наличие валидных учетных записей. Поэтому не начинайте менять ключи и редактировать конфигурационные файлы. Выполните одну команду, прочитайте три строки вывода, и пять возможных причин сократятся до одной.

Сначала выполните ssh -v и изучите три строки

Повторите команду, которая завершилась ошибкой, добавив -v:

ssh -v deploy@203.0.113.10

Сокращенный, но реалистичный вывод выглядит так:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

Три строки содержат всю необходимую информацию.

Authenticating to 203.0.113.10:22 as 'deploy' — это имя пользователя, которое будет фактически использовано. Не то, которое вы планировали, а то, которое ssh определил на основе командной строки, ~/.ssh/config или вашего локального имени пользователя.

Authentications that can continue: publickey — это список методов, принятых сервером, который отправляется до попытки использования любого ключа. Если publickey отсутствует в этом первом списке, значит, на сервере отключен вход по открытому ключу, поэтому ни один ключ не сработает.

Offering public key: ... — это по одной строке на каждый ключ, который клиент действительно отправил, с указанием файла, из которого он был взят, и его SHA256-отпечатка. Ключ, для которого нет строки Offering, никогда не отправлялся на сервер.

Теперь разделите проблему на две части:

• Отсутствует строка Offering public key для ожидаемого вами ключа. Ошибка на вашей стороне, так как сервер вообще не видел ваш ключ.
• Ключ предложен, но снова возвращается Authentications that can continue: publickey. Сервер получил этот ключ и отклонил его, значит, ошибка на стороне сервера.

Причины ниже упорядочены по частоте их возникновения.

Причина 1: вы подключаетесь под неверным именем пользователя

Самая частая причина — одновременно и самая банальная. sshd, демон сервера SSH (secure shell), никогда не сообщает, что учетная запись не существует. Он проводит весь процесс обмена данными для вымышленного имени пользователя и в конце выдает тот же отказ, так как разглашение существующих имен учетных записей помогает злоумышленнику. Опечатка в имени пользователя выглядит точно так же, как неисправный ключ.

Прежде всего проверьте строку Authenticating to ... as. Если там указано имя пользователя вашего ноутбука, а не учетная запись на сервере, значит, вы не указали имя пользователя в команде.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

Учетная запись по умолчанию зависит от образа, подготовленного вашим провайдером. По состоянию на август 2026 года, облачные образы Ubuntu обычно содержат учетную запись ubuntu, образы Debian — debian или admin, Rocky Linux и AlmaLinux — rocky и almalinux, а многие VPS-провайдеры сразу устанавливают ваш ключ в root. Панель управления вашего провайдера содержит информацию о том, какая учетная запись была создана. Никакая команда, запущенная снаружи сервера, не может это выяснить.

Блок Host в файле ~/.ssh/config также задает имя пользователя, и его значение имеет приоритет над вашим локальным именем для входа:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Если вы создали учетную запись самостоятельно, а затем не смогли войти под ней, вероятно, ключ был установлен для пользователя по умолчанию из образа и не был скопирован. Этот шаг является частью руководства первые десять минут на новом VPS, и его легко пропустить.

Причина 2: вы используете не тот ключ, который отправляется на сервер

По умолчанию ssh предлагает только ключи, хранящиеся в ssh-agent, а также фиксированный набор файлов в ~/.ssh: id_ed25519, id_ecdsa, id_rsa, а также их аппаратные и DSA-варианты. Ключ, сохранённый как ~/.ssh/vps-prod, невидим для ssh, пока вы не укажете его явно; именно поэтому в подробном выводе отсутствует строка Offering public key для этого файла.

Укажите имя файла и предотвратите использование ключей из агента:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

Одного -i недостаточно, если в агенте есть ключи, так как ssh всё равно сначала предлагает ключи агента, а указанный файл — в последнюю очередь. Это важно, так как сервер учитывает каждый отклонённый ключ в лимите MaxAuthTries, который по умолчанию равен 6. Если в агенте семь ключей, лимит будет исчерпан до того, как очередь дойдёт до вашего правильного ключа, и сообщение изменится на:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

Если вместо этого отображается такое сообщение, сервер завершил сеанс до того, как была проверена нужная криптографическая key. Это описано в разделе слишком много неудачных попыток аутентификации. IdentitiesOnly=yes ограничивает попытку файлом, который вы указали. Просмотрите ключи, загруженные в агент, с помощью ssh-add -l. Если там накопились старые ключи за несколько лет, удалите их с помощью ssh-add -D. Затем сохраните параметры в конфигурации, чтобы при следующем входе не приходилось запоминать flags:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod исправляет эту проблему. Перенос ключей через USB-накопители или общие папки Windows — обычная причина потери прав доступа. О том, где хранить ключи и как их называть, рассказано в Основы управления SSH-ключами.

Причина 3: открытый ключ не был добавлен в authorized_keys

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

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

Команда ssh-keygen -lf для файла authorized_keys выводит по одному отпечатку ключа на каждую запись:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

Сравните их с отпечатком в вашей строке Offering public key. Если его нет в списке, значит, ключ не установлен для этой учетной записи, независимо от того, что вы помните.

Существует четыре распространенные ошибки:

• Вы вставили закрытый ключ вместо содержимого файла .pub. Строка открытого ключа начинается с ssh-ed25519 или ssh-rsa. Закрытый ключ начинается с -----BEGIN OPENSSH PRIVATE KEY-----.
• При вставке ключ разбился на несколько строк. Каждая запись должна располагаться строго на одной строке, поэтому перенос строки делает ключ нечитаемым, и совпадение не находится.
• Ключ был добавлен в /root/.ssh/authorized_keys, в то время как вы входите под пользователем deploy, или наоборот. Файл привязан к конкретной учетной записи, общего файла не существует.
• Поле «добавить мой ключ» в панели провайдера добавило его только для пользователя по умолчанию, поэтому в учетной записи, которую вы создали позже, каталог .ssh пуст.

Безопасный способ добавить ключ через консоль от имени root:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

После этого снова выполните sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys. Новый отпечаток должен появиться в списке. Если у вас есть доступ к машине, на которую еще можно войти по паролю, команда ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 выполнит ту же работу и автоматически установит правильные права доступа.

Причина 4: почему sshd игнорирует authorized_keys при слишком открытых правах доступа

StrictModes yes — это значение по умолчанию для sshd. Согласно ему, sshd отказывается читать authorized_keys, если этот файл, каталог .ssh или домашний каталог учетной записи доступны для записи кому-либо, кроме владельца. Причина проста: если группа или другие пользователи могут записывать данные в ваш домашний каталог, любая учетная запись с таким доступом может заменить authorized_keys и перехватить вход в систему. sshd считает небезопасный путь таким, будто ключа не существует вовсе.

Клиент получает стандартное сообщение Permission denied. В журнале сервера фиксируется реальная причина:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

или, если проблема в самом файле:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

Что принимает sshd:

• Домашний каталог: не должен быть доступен для записи группе или всем остальным. 755, 750 и 700 подходят. 775 и 777 вызывают ошибку.
• ~/.ssh: режим 700.
• ~/.ssh/authorized_keys: режим 600.
• Владение: все три объекта должны принадлежать учетной записи, под которой вы входите, а не root.

Владение так же важно, как и права доступа. Файл внутри /home/deploy/.ssh, принадлежащий root, не пройдет проверку; это случается, если вы создали его через sudo nano и забыли сменить владельца. Исправьте обе проблемы сразу:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

Последняя команда показывает результат. Вам нужно drwxr-xr-x или более строгие права для домашнего каталога и drwx------ для .ssh. Если эти строки пока не очевидны, прочитайте как читать строку прав доступа, например drwxr-xr-x, прежде чем менять режимы на рабочем сервере.

В Rocky Linux и AlmaLinux добавьте SELinux (security-enhanced Linux) в список подозреваемых. Каталог .ssh, созданный нестандартным способом, может иметь неверную метку файла, поэтому sshd будет отказано в доступе на чтение, даже если права доступа выглядят корректно. sudo restorecon -Rv /home/deploy/.ssh восстанавливает метки, а sudo ausearch -m avc -ts recent показывает, был ли SELinux тем компонентом, который блокировал доступ.

Причина 5: конфигурация sshd запрещает вам доступ

Чтения /etc/ssh/sshd_config недостаточно в современных системах Ubuntu или Debian. Этот файл начинается с Include /etc/ssh/sshd_config.d/*.conf, а OpenSSH всегда использует первое найденное значение для любой настройки. Поэтому файл конфигурации из директории с дополнениями, такой как 50-cloud-init.conf, считывается первым и имеет приоритет над любыми изменениями, внесенными ниже в основном файле. Именно поэтому правки могут выглядеть верными, но не приводить к результату.

Запросите у sshd конфигурацию, которую он фактически использует:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

Корректный ответ выглядит так:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

На что обратить внимание в выводе:

• pubkeyauthentication no. Ни один ключ не будет принят. Это также отображается в ssh -v как первый список Authentications that can continue:, в котором нет publickey.
• authorizedkeysfile, указывающий на другой путь, например /etc/ssh/authorized_keys/%u. В этом случае ваш файл в домашней директории полностью игнорируется, а правила прав доступа из причины 4 применяются к новому пути.
• Наличие allowusers или allowgroups. Любая учетная запись, не указанная в списке, получает отказ именно с этой ошибкой без дополнительных пояснений. denyusers и denygroups работают аналогичным образом, но в обратном порядке.
• permitrootlogin no при попытке входа под пользователем root. prohibit-password — это оптимальная промежуточная настройка: root может использовать ключ, но не пароль.

Блоки Match не отображаются в обычном sshd -T, так как их результат зависит от того, кто именно подключается. Запросите информацию для конкретного соединения:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Еще одна настройка влияет на старые ключи. Начиная с версии 8.8, OpenSSH по умолчанию перестал принимать подписи SHA-1 (ssh-rsa), поэтому RSA-ключ, работавший годами, может перестать функционировать сразу после обновления сервера. Клиент сообщает об этом прямо:

debug1: send_pubkey_test: no mutual signature algorithm

Правильное решение — создание нового ключа: ssh-keygen -t ed25519 -C "deploy@vps-prod", затем установите файл .pub, как показано выше. Настройка PubkeyAcceptedAlgorithms +ssh-rsa на сервере повторно включает старые подписи и позволяет войти в систему прямо сейчас, поэтому рассматривайте это лишь как способ получить доступ к серверу, а не как окончательное решение. Остальные настройки серверной части, которые стоит изучить, описаны в укреплении безопасности SSH-сервера на VPS.

Как доказать, что закрытый ключ соответствует установленному открытому ключу

Большая часть догадок при возникновении этой ошибки связана с тем, что неизвестно, составляют ли два файла пару. Один единственный метод позволяет это выяснить:

ssh-keygen -y -f ~/.ssh/vps-prod

Эта команда выводит открытый ключ, полученный из закрытого. Она не считывает файл .pub, расположенный рядом, поэтому показывает, чем закрытый ключ является на самом деле, а не то, что утверждает устаревший файл .pub. Если ключ защищен парольной фразой, команда запросит её, что также подтвердит, что вы всё ещё знаете этот пароль.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

Первая команда выводит отпечаток (fingerprint) одного файла открытого ключа. Вторая выводит отпечатки ключей, которые хранятся в вашем агенте. Теперь сопоставьте четыре представления одной и той же строки: отпечаток в строке Offering public key из ssh -v, отпечаток вашего файла .pub, отпечатки в ssh-keygen -lf внутри authorized_keys на сервере и отпечаток в журнале сервера. То место, где они перестают совпадать, и является источником вашей ошибки.

Чтение лога сервера во время неудачной попытки входа

Клиенту намеренно не сообщается полезная информация. Сервер записывает истинную причину ошибки. Запустите утилиту для отслеживания лога в консольной сессии, затем выполните команду ssh, которая завершается ошибкой, с вашего ноутбука.

sudo journalctl -u ssh -f

В Ubuntu 24.04 по умолчанию не устанавливается rsyslog, поэтому файл /var/log/auth.log может отсутствовать. В Rocky Linux и AlmaLinux юнит называется sshd, а те же записи попадают в /var/log/secure.

Установите LogLevel VERBOSE в конфигурации sshd и перезагрузите сервис. После этого каждая попытка входа будет записывать в лог отпечаток ключа, который фактически получил сервер:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

Эта строка указывает, на чьей стороне возникла проблема. Если вы узнаете отпечаток, значит, ваш ключ дошел до сервера, но был отклонен — в этом случае изучите причины 3, 4 и 5. Если отпечаток вам не знаком, значит, клиент отправил не тот ключ, который вы планировали использовать — вернитесь к причине 2.

Если лог по-прежнему не дает ясности, запустите второй экземпляр sshd на другом порту в режиме отладки. Он будет работать в интерактивном режиме, обработает одно соединение, выведет подробную информацию о своих действиях и завершится:

sudo /usr/sbin/sshd -ddd -p 2222

Из консольной сессии на том же сервере подключитесь к нему через loopback-адрес:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

Использование 127.0.0.1 позволяет исключить влияние межсетевого экрана на тест. В отладочном выводе будут указаны открытый файл, отпечаток для сравнения и точная причина отказа, включая такие строки, как Authentication refused: bad ownership or modes for directory /home/deploy. Нажмите Ctrl+C, когда получите ответ. Основной процесс sshd на порту 22 при этом никак не затрагивается.

Как избежать потери доступа к серверу

Любое действие по изменению конфигурации сервера требует наличия резервного способа входа, не зависящего от SSH. Настройте его, пока SSH работает, а не после того, как доступ будет потерян.

1. Откройте консоль вашего провайдера через serial или VNC (virtual network computing) и убедитесь, что можете войти в систему.
2. Убедитесь, что вы знаете рабочий локальный пароль для учетной записи с правами sudo. Если его нет, сначала сбросьте пароль root через консоль провайдера.
3. Не закрывайте текущую SSH-сессию. Открытая сессия сохраняется при systemctl restart ssh, поэтому она останется способом входа, если новая конфигурация окажется ошибочной.
4. Проверьте синтаксис перед перезапуском: sudo sshd -t ничего не выводит, если файл корректен, и указывает файл и номер строки при наличии ошибок.
5. Откройте второй терминал и выполните новый вход, прежде чем закрывать первый. Некорректная конфигурация блокирует новые подключения, но оставляет активными существующие, поэтому текущая сессия не покажет, применились ли изменения.

Выполните перезапуск с помощью sudo systemctl restart ssh в Debian и Ubuntu или sudo systemctl restart sshd в Rocky Linux и AlmaLinux. В Ubuntu 24.04 служба sshd запускается через socket unit, поэтому для применения изменений в Port или ListenAddress также необходимо выполнить sudo systemctl restart ssh.socket.

FAQ

Почему я получаю ошибку Permission denied (publickey), хотя этот же ключ работает на другом сервере?

Потому что с ключом всё в порядке, а проблема в окружении. Запустите ssh -v и найдите строку Offering public key. Если вашего ключа там нет, значит, ssh его не отправил: файл отсутствует в ~/.ssh под стандартным именем и не загружен в агент, поэтому добавьте его через -i /path/to/key -o IdentitiesOnly=yes. Если ключ в списке, а сервер всё равно отказывает в доступе, значит, этот ключ отсутствует в файле authorized_keys учётной записи, путь к нему доступен для записи группе или конфигурация sshd блокирует пользователя. Лог сервера позволяет различить эти случаи.

Как увидеть, какой именно ключ отправляет SSH?

ssh -v host выводит по одной строке debug1: Offering public key: для каждого ключа, указывая исходный файл и SHA256-отпечаток. ssh-add -l перечисляет отпечатки, хранящиеся в агенте. ssh-keygen -lf ~/.ssh/id_ed25519.pub выводит отпечаток отдельного файла ключа, а ssh-keygen -y -f ~/.ssh/id_ed25519 показывает публичный ключ, соответствующий приватному. Чтобы вход в систему прошёл успешно, отпечаток из строки Offering должен совпадать с результатом выполнения ssh-keygen -lf для файла authorized_keys на сервере.

Почему sshd игнорирует мой файл authorized_keys?

Потому что опция StrictModes включена по умолчанию, и либо сам файл, либо каталог .ssh, либо домашний каталог доступны для записи группе или всем пользователям, либо принадлежат не той учётной записи. sshd не доверяет пути, который может изменить кто-то другой, поэтому ведёт себя так, будто ключей нет. Установите права на домашний каталог 755 или строже, для .ssh — 700, для authorized_keys — 600, и убедитесь, что все три объекта принадлежат пользователю, под которым вы входите. С помощью LogLevel VERBOSE сервер записывает причину в Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Мой ключ перестал работать сразу после обновления сервера. Что изменилось?

Если это RSA-ключ, скорее всего, дело в отказе от SHA-1. В OpenSSH 8.8 по умолчанию отключены подписи ssh-rsa SHA-1, поэтому ключ, который может подписывать только так, теперь отклоняется. Подробный вывод клиента покажет debug1: send_pubkey_test: no mutual signature algorithm. Создайте современный ключ с помощью ssh-keygen -t ed25519 и установите его файл .pub. Если доступ нужен немедленно, добавьте PubkeyAcceptedAlgorithms +ssh-rsa в конфигурацию сервера, чтобы снова разрешить старые подписи, но удалите эту строку, как только заработает новый ключ.

Я отредактировал sshd_config и теперь вообще не могу войти. Как восстановить доступ?

Используйте консоль вашего провайдера, которая работает в обход SSH. Войдите в систему с локальным паролем, выполните sudo sshd -t, чтобы увидеть синтаксическую ошибку и номер строки, отмените изменения и перезапустите службу. Затем проверьте sudo sshd -T, чтобы подтвердить текущие значения параметров, так как файл в /etc/ssh/sshd_config.d/ может переопределять основную конфигурацию. Если локального пароля нет, сначала сбросьте пароль root через консоль, а затем исправьте файл.