SSH: Too many authentication failures

#Что означает ошибка

Received disconnect from ...: Too many authentication failures означает, что SSH-клиент перебрал слишком много ключей, и сервер закрыл соединение до того, как дошла очередь до нужного (по умолчанию сервер допускает 6 попыток, MaxAuthTries). Если у вас в ssh-agent много ключей, ошибка возникает даже при правильном пароле.

Решение — указать клиенту конкретный ключ и запретить перебор.

Диагностика показывает порядок предлагаемых ключей.

SSH перебирает все доступные ключи агента, и сервер отключает клиента после нескольких неудачных попыток. Укажите конкретный ключ и параметр IdentitiesOnly.

#Причины и решения

#Пошаговое решение

1. Запустите ssh -vНа своём компьютере откройте терминал и выполните ssh -vvv пользователь@хост, сохранив лишь диагностические строки Offering public key и Too many authentication failures (не публикуйте токены и приватные ключи). Эта ошибка часто возникает, когда ssh-agent предлагает много ключей до нужного, даже если пароль правильный.
2. Укажите конкретный ключНайдите путь к нужному приватному ключу, затем выполните ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 пользователь@хост, подставив реальный ключ и хост. IdentitiesOnly=yes ограничит используемые идентификаторы; если ключ не подходит, проверьте, что соответствующий публичный ключ установлен на сервере.
3. Очистите ssh-agentКоманда ssh-add -D удаляет все идентификаторы из вашего ssh-agent и может нарушить доступ к другим серверам. Вместо этого сначала посмотрите ssh-add -l, определите лишние ключи и используйте разовый IdentitiesOnly=yes для конкретного подключения. Очищайте агент лишь если знаете, как вернуть все необходимые ключи.
4. Настройте ~/.ssh/configДля постоянного решения откройте ~/.ssh/config в редакторе на клиенте, создайте блок Host рабочее-имя, укажите HostName, User, IdentityFile и IdentitiesOnly yes для этого сервера. Права файла на Linux/macOS не должны позволять сторонним запись; проверьте ssh -G рабочее-имя | grep -E "identityfile|identitiesonly".
5. Проверьте права и authorized_keys на сервереЕсли сервер всё равно отказывает, администратор сервера через консоль проверяет ~/.ssh/authorized_keys, владельцев домашнего каталога и .ssh, а также журнал sshd. Не меняйте парольные методы и не отключайте MaxAuthTries глобально, пока не установлено, что причина именно в количестве предложенных ключей.
6. Использовать только указанный ключ

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Использовать только указанный ключ.

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

#Диагностика

Запустите ssh -v user@host и посмотрите строки Offering public key: — сколько ключей предлагается до отказа. Список ключей агента: ssh-add -l. Проверьте ~/.ssh/config на IdentityFile и IdentitiesOnly. На сервере в /var/log/auth.log (или journalctl -u ssh) видны причины отказа.

#Исправление на клиенте

Укажите нужный ключ и отключите перебор: ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@host. Постоянно: в ~/.ssh/config: Host server → HostName 203.0.113.10 → User user → IdentityFile ~/.ssh/id_ed25519 → IdentitiesOnly yes. Лишние ключи из агента удалите: ssh-add -D, затем ssh-add ~/.ssh/id_ed25519. Для входа по паролю: ssh -o PubkeyAuthentication=no user@host.

#Сервер

Увеличьте лимит в /etc/ssh/sshd_config: MaxAuthTries 6 (по умолчанию), примените sudo sshd -t && sudo systemctl reload ssh. Лучше не увеличивать, а настроить клиента. Проверьте, что ключ добавлен в ~/.ssh/authorized_keys с правами 600 и каталог .ssh с 700, а домашняя папка не доступна для записи группе. Fail2ban может блокировать IP после неудачных попыток: sudo fail2ban-client status sshd.