Too many authentication failures: как заставить SSH предложить нужный ключ

Правильный SSH-ключ лежит на месте, но сервер обрывает вход сообщением Too many authentication failures. Пароль ещё не спрашивали, а нужный ключ будто игнорируется. Частая причина — агент хранит несколько ключей, и клиент предлагает их раньше, чем добирается до подходящего. Сервер ограничивает число неуспешных попыток внутри соединения.

Посмотрите порядок предложений

ssh-add -l
ssh -v deploy@app.example

Первая команда показывает идентичности агента, если он доступен. Во второй найдите строки Offering public key. Сопоставьте fingerprint нужного ключа и момент обрыва. Если сервер прекращает соединение до его предложения, копирование того же публичного ключа в authorized_keys не меняет порядок на клиенте.

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

Ограничьте выбор для одного сервера

Host app-lab
    HostName app.example
    User deploy
    IdentityFile ~/.ssh/id_ed25519_app
    IdentitiesOnly yes

Сохраните блок в пользовательском конфиге, затем проверьте ssh app-lab. IdentitiesOnly ограничивает предлагаемые идентичности настроенными ключами вместо произвольного набора агента. Это не выключает все возможности агента: он всё ещё может выполнить подпись соответствующим разрешённым ключом.

Одна опция IdentityFile без IdentitiesOnly не всегда решает проблему: клиент может продолжить предлагать дополнительные ключи агента. В то же время несколько IdentityFile из совпавших блоков конфигурации могут накапливаться. Поэтому после правки посмотрите рассчитанные identityfile через ssh с опцией G.

Прочитайте новый результат

Если нужный ключ теперь предлагается первым и сервер его принимает, причина найдена. Если он предлагается, но отвергается, исследование переходит на сервер: пользователь, содержимое разрешённых ключей, ограничения ключа и политика аутентификации. Эти случаи нельзя объединять под общей фразой «SSH не видит ключ».

Если после принятия ключа запрашивается второй фактор, это тоже отдельный этап. Успешная публичная аутентификация может быть частью составной политики. Не отключайте остальные требования только для того, чтобы команда перестала спрашивать данные.

Увеличивать MaxAuthTries на сервере ради переполненного клиентского агента обычно не нужно. Это меняет политику для других подключений и оставляет причину на рабочей машине. Удалять все ключи из агента тоже неудобно, когда они нужны для разных проектов. Отдельные Host-блоки дают локальное и объяснимое решение.

Завершите проверку новым независимым соединением, если используется ControlMaster. Существующий master может скрыть повторную аутентификацию. В runbook сохраните псевдоним хоста и ожидаемый fingerprint пользовательского ключа.

Продолжите от настройки ключа к сопровождению сервера. В курсе Linux и Bash для DevOps-инженеров есть работа с окружением, пользователями и доступами. Откройте программу, чтобы отрабатывать изменения на учебном узле и проверять каждый этап входа осмысленно.

Ещё по теме

• После переустановки сервера изменился SSH host key: как обновить доверие
• Внутренняя панель через SSH-туннель: где открывается порт и кто идёт к сервису