SSH: «Too Many Authentication Failures» — что это и как исправить
При подключении к серверу по SSH иногда появляется сообщение вида: Received disconnect from x.x.x.x port 22:2: too many authentication failures или ssh: Permission denied (publickey).
По сути это значит, что клиент не смог пройти проверку на удалённой стороне, исчерпав лимит попыток. Ниже — почему так происходит, как это устроено и что сделать, чтобы подключение заработало и в будущем не срывало работу именно для этого соединения.
Примеры приведены для Ubuntu 24.04, но логика одинакова и для других дистрибутивов.
Почему возникает ошибка
SSH поддерживает несколько способов входа. Чаще всего это вход по ключу и вход по паролю. Авторизация по ключу считается базовым и безопасным вариантом, поэтому серверы обычно предлагают её в первую очередь. Клиент получает от сервера список допустимых методов и перебирает их в заданном порядке. Число попыток ограничено: если «правильный» способ не срабатывает вовремя, соединение обрывается с ошибкой.
Если вы планировали вход по ключу, сбой обычно связан с одним из следующих моментов:
— Публичный ключ не добавлен на сервер. На вашей машине должен лежать приватный ключ, а соответствующий публичный — находиться на удалённой стороне в ~/.ssh/authorized_keys.
— Ключ не подхватывается ssh-agent. Перенести файлы в ~/.ssh недостаточно: ключи нужно добавить командой ssh-add.
— В системе слишком много ключей. Клиент пробует первые несколько, упирается в лимит попыток и получает отказ, даже если «нужный» ключ есть.
Если же вы хотели войти по паролю, нюансы другие:
— Сервер объявляет поддержку ключей. При большом числе локальных ключей клиент будет пробовать их и до ввода пароля дело не дойдёт.
— Выбран не тот механизм парольной авторизации. В SSH есть как минимум два варианта — password и keyboard-interactive. Если клиент пытается password, а сервер ждёт keyboard-interactive, вы получите отказ.
Как разобраться, что именно не так
Для начала нужно проанализировать подробный вывод клиента. Добавьте к команде опцию -vvv:
ssh -vvv serhii@192.168.56.124
В логе подключения обратите внимание на строку с preferred — в ней перечислен порядок методов, которые клиент будет пробовать. Полезно также посмотреть, какие ключи агент реально предлагает (get_agent_identities), и на каком этапе происходит отказ.
Как исправить: рабочие сценарии
Далее мы собрали минимальные настройки на стороне клиента, которые чаще всего решают проблему. Предположим, что сервер настроен корректно и готов пускать как по ключу, так и по паролю.
1) Отключаем перебор «всех подряд» ключей
По умолчанию SSH клиент перебирает все найденные ключи, легко упираясь в лимит. Заставьте его использовать только те ключи, которые вы указали:
В /etc/ssh/ssh_config добавьте:
IdentitiesOnly yes
После этого клиент будет использовать строго те ключи, что перечислены в конфигурации через IdentityFile. Уже на этом этапе ошибка «too many authentication failures» часто исчезает. Если взамен появилась Permission denied (publickey), переходите к следующему пункту.
2) Указываем нужный ключ
Передайте путь к приватному ключу в командной строке:
ssh -o IdentityFile=~/.ssh/id_ed25519_7 serhii@192.168.124.58
Чтобы не писать опцию каждый раз, добавьте правило в ~/.ssh/config:
Host 192.168.124.58
IdentityFile ~/.ssh/id_ed255
Теперь этот ключ будет использоваться для всех подключений к указанному хосту.
3) Принудительно входим по паролю
Если вам нужен именно пароль, а локально лежат ключи, задайте порядок методов и отключите авторизацию по ключу:
ssh \
-o PubkeyAuthentication=no
-o PasswordAuthentication=yes
-o PreferredAuthentications=password
serhii@192.168.124.58
То же самое можно зафиксировать в ~/.ssh/config:
Host 192.168.124.58
PubkeyAuthentication no
PasswordAuthentication yes
PreferredAuthentications password
4) Меняем механизм на keyboard-interactive
Иногда сервер ждёт keyboard-interactive (например, при внешних системах аутентификации). В этом случае используйте:
ssh \
-o PubkeyAuthentication=no
-o PreferredAuthentications=keyboard-interactive
name@192.168.124
И соответствующее правило в конфиге:
Host 192.168.124.58
PubkeyAuthentication no
PreferredAuthentications keyboard-interactive
Что проверить на сервере
Если есть доступ к консоли сервера или к его системным логам, сделайте две вещи.
Логи.
Включите расширенный уровень для демона SSH, добавив в /etc/sshd_config строку:
LogLevel VERBOSE
Затем перезапустите службу:
sudo systemctl restart ssh
По умолчанию сообщения об авторизации пишутся в /var/log/auth.log.
Права доступа.
Файл ~/.ssh/authorized_keys должен иметь права 600:
ls -l ~/.ssh/authorized_keys
Итого
Ошибка too many authentication failures (а иногда и Permission denied (publickey)) почти всегда сводится к двум вещам: клиент перебирает не те ключи или стороны договорились о разных способах входа. Включите подробный вывод (-vvv), ограничьте используемые ключи (IdentitiesOnly + IdentityFile) или явно задайте нужный метод авторизации. Если нужно — загляните в серверные логи и проверьте права на authorized_keys.