Как исправить ошибку 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

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

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

Ещё одна ловушка на стороне клиента. ssh отказывается использовать закрытый ключ, если другие учётные записи на вашей машине имеют права на его чтение. В этом случае 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 или более строгие права, а для .ssh — drwx------. Если эти строки пока не очевидны, прочитайте как читать строку прав доступа вроде 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

Первая команда выводит отпечаток файла открытого ключа. Вторая выводит отпечатки ключей, которые хранятся в вашем агенте. Теперь сопоставьте четыре представления одной и той же строки: отпечаток в строке 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. Откройте консоль вашего провайдера через последовательный порт или 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 через консоль, а затем исправьте файл.