SSH не подключается: Permission denied, host key changed и другие ошибки

Сначала определите этап, на котором остановился SSH

OpenSSH устанавливает TCP-соединение, согласует криптографические параметры, проверяет ключ удалённого хоста и только затем аутентифицирует пользователя. Поэтому одна и та же внешняя картина — «не могу войти» — имеет разные причины и требует разных действий.

Как читать ssh -v и почему одного вывода клиента недостаточно

Диагностические ключи, формат строк и доступные параметры зависят от версии OpenSSH. Ориентируйтесь на man-страницы ssh(1) и ssh_config(5) той системы, где запускается клиент. Обычно -v достаточно для первичной проверки, а -vvv показывает выбор конфигурации, файлов ключей и ход аутентификации подробнее.

ssh -vvv user@example.example

• Строки о Connecting to и Connection established подтверждают попытку TCP-подключения, но не доказывают, что дальше отвечает именно ожидаемый sshd.
• Строки вида Server host key: или Host key verification failed относятся к проверке сервера и предшествуют аутентификации пользователя.
• Offering public key означает, что клиент предлагает ключ; Server accepts key означает, что сервер согласился на этот ключ и запросил подпись. Если после этого вход не завершился, ищите дальнейшие сообщения и серверные журналы.
• Authentications that can continue: publickey,password — перечень методов, допустимых сервером на этом этапе. Он не доказывает, что конкретный уже предложенный ключ был отвергнут именно из-за отсутствия в authorized_keys.
• Connection closed by ... на стороне клиента фиксирует факт закрытия сокета. Без журналов сервера, прокси или сетевого устройства нельзя надёжно приписать разрыв сети, sshd либо промежуточному устройству.

SSH host key changed: как безопасно подтвердить смену ключа

Предупреждение REMOTE HOST IDENTIFICATION HAS CHANGED означает, что клиент получил для указанного имени или адреса ключ, отличный от сохранённого ранее. Легитимные причины: VM пересоздали, ОС переустановили, ключи хоста заменили в плановом порядке, DNS-имя или IP теперь указывает на другой узел, либо за балансировщиком оказался иной сервер. Но те же симптомы возможны при атаке «человек посередине» или компрометации инфраструктуры.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

ssh-keygen -F example.example

ssh-keygen -R example.example

Подробнее о проверке отпечатка ключа SSH, создании ключей и устройстве known_hosts — в статье «Безопасная настройка SSH: ключи, root и ограничение доступа».

Permission denied (publickey): что проверить, если ключ есть в authorized_keys

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

ssh -vvv -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@example.example

IdentityFile задаёт дополнительный файл идентичности клиента; несколько таких параметров могут накапливаться. IdentitiesOnly yes ограничивает использование идентичностями, явно заданными в конфигурации или командной строке, даже если SSH-агент хранит другие ключи. IdentityAgent задаёт сокет агента либо отключает его для конкретного назначения. PreferredAuthentications меняет порядок и набор предпочитаемых методов, но сам по себе не выбирает конкретный файл ключа. Точное поведение и доступность параметров смотрите в ssh_config(5) используемой версии.

SSH key: неправильные права на закрытый ключ клиента

На Unix-подобных системах OpenSSH обычно отказывается использовать локальный закрытый ключ, если файл доступен другим пользователям. В выводе встречается сообщение наподобие UNPROTECTED PRIVATE KEY FILE! и This private key will be ignored. Это защита секрета, а не ошибка сервера. Точные проверки режимов и ACL зависят от ОС, файловой системы и реализации клиента.

chmod 600 ~/.ssh/id_ed25519 && chmod 700 ~/.ssh

Права и владельцы authorized_keys на сервере

Директива StrictModes в sshd_config заставляет sshd проверять владельца и режимы файлов пользователя и домашнего каталога до принятия входа. В типичной локальной конфигурации домашний каталог принадлежит пользователю, ~/.ssh имеет режим 700, а ~/.ssh/authorized_keys — 600; они не должны быть доступны на запись группе или всем. Стандартный либо настроенный путь к ключам определяет AuthorizedKeysFile, поэтому не предполагайте, что sshd читает только ~/.ssh/authorized_keys.

namei -l /home/user/.ssh/authorized_keys && ls -ld /home/user /home/user/.ssh && ls -l /home/user/.ssh/authorized_keys

chown -R user:user /home/user/.ssh && chmod 700 /home/user/.ssh && chmod 600 /home/user/.ssh/authorized_keys

На системах с SELinux или AppArmor обычные Unix-права могут быть корректны, но доступ sshd всё равно будет запрещён политикой. Не отключайте механизм мандатного контроля для проверки: разберите отказ и контекст по инструкции «SELinux на сервере» либо «AppArmor на сервере».

Too many authentication failures: как ограничить лишние ключи агента

Ошибка Too many authentication failures обычно означает, что sshd исчерпал лимит попыток аутентификации до того, как клиент дошёл до правильного ключа. Ограничение на сервере задаёт MaxAuthTries в sshd_config(5); конкретное значение может быть изменено администратором. Увеличение лимита или отключение его защиты ради одного клиента обычно хуже, чем передать нужный ключ явно.

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@example.example

Host app-prod
    HostName example.example
    User user
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Если необходимо использовать отдельный агент, задайте для этого хоста IdentityAgent в соответствии с ssh_config(5) или временно отключите агент для подключения. PreferredAuthentications publickey может поставить метод ключа первым, но не решает проблему множества ключей без IdentitiesOnly или корректного IdentityAgent. Посмотреть ключи текущего агента обычно можно командой ssh-add -l; не удаляйте ключи из общего агента, если ими пользуются другие сессии или процессы.

Корректный ключ, но вход запрещён: sshd, Match, PAM и учётная запись

Даже принятый ключ не отменяет правила доступа. Вход могут запретить AllowUsers, AllowGroups, DenyUsers, DenyGroups, условия Match, запрет интерактивной оболочки, срок действия или блокировка учётной записи, а также PAM. Внешние источники идентификационных данных — например LDAP или доменные службы — добавляют собственные условия.

sudo sshd -t

sudo sshd -T -C user=user,host=client.example.example,addr=192.0.2.10

Проверяйте Match именно с параметрами реального подключения: правило может зависеть от пользователя, исходного адреса, имени, локального адреса или порта. Строка в основном файле конфигурации не гарантирует итоговое значение, если используются включаемые фрагменты или более специфичные правила.

getent passwd user

Для локальных Linux-учётных записей срок действия и статус часто проверяют штатными утилитами семейства ОС, но их вывод и полномочия различаются. Настройка PAM-политики, сроков действия и процедуры разблокировки разобрана отдельно в «Учётные записи, sudo и парольная политика в Linux».

Где искать журналы sshd

Единого пути к журналу SSH для всех Linux-дистрибутивов нет. В системах с systemd события обычно доступны через journal; в одних семействах дистрибутивов аутентификация дополнительно попадает в /var/log/auth.log, в других — в /var/log/secure. Название systemd-службы также может быть ssh или sshd.

sudo journalctl -u sshd --since '15 minutes ago'

sudo grep -Ei 'sshd|Accepted|Failed|authentication|authorized_keys|PAM' /var/log/auth.log /var/log/secure 2>/dev/null

Неподдерживаемый алгоритм, отозванный ключ и no hostkeys available