sshd: Too many authentication failures
Сообщение о слишком большом числе неудачных попыток обычно не связано с подбором пароля: клиент предлагает по очереди все ключи из агента, и сервер обрывает соединение, исчерпав допустимое число попыток.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
В агенте много ключей
Клиент предлагает их все. Если подходящий стоит десятым, сервер успевает прервать соединение раньше.
-
Ограничение на стороне сервера слишком строгое
Параметр
MaxAuthTriesпо умолчанию равен шести. При большом числе ключей у клиентов этого мало. -
Ключи не подходят вовсе
Если на сервере нет ни одного из ваших ключей, перебор закончится отказом независимо от их числа.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Сколько ключей предлагает агент.
ssh-add -lКакие ключи предлагались и что ответил сервер.
ssh -vv user@host 2>&1 | tail -30Подтверждение со стороны сервера.
sudo journalctl -u ssh -n 30 --no-pager | grep -i "too many"Решение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Клиент предлагает их все. Если подходящий стоит десятым, сервер успевает прервать соединение раньше.
- Как проверить
-
Посмотрите список ключей в агенте.
ssh-add -l | head -20
- Как исправить
-
Укажите нужный ключ явно и запретите перебор: ключ
IdentitiesOnly=yesвместе сIdentityFile.ssh -o IdentitiesOnly=yes -i ~/.ssh/id_prod user@host
- Почему происходит
- Параметр
MaxAuthTriesпо умолчанию равен шести. При большом числе ключей у клиентов этого мало.
- Как проверить
-
Посмотрите действующее значение.
sudo sshd -T | grep -i maxauthtries
- Как исправить
- Значение можно поднять, но лучше починить сторону клиента: рост предела ослабляет защиту от подбора.
- Почему происходит
- Если на сервере нет ни одного из ваших ключей, перебор закончится отказом независимо от их числа.
- Как проверить
-
Посмотрите подробный вывод клиента и журнал сервера.
ssh -vv user@host 2>&1 | grep -iE "offering|authentications that can continue" | head
- Как исправить
- Добавьте нужный открытый ключ в файл authorized_keys на сервере.
Пример вывода
Клиент перебрал ключи из агента. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
sshd[5400]: error: maximum authentication attempts exceeded for user from <адрес> port N ssh2 [preauth]
sshd[5400]: Disconnecting authenticating user user <адрес> port N: Too many authentication failures [preauth]Связанные ошибки
- sshd: отказ аутентификации из-за прав на файлы Вход по ключу не работает: слишком широкие права на домашний каталог или authorized_keys. Разбор через журнал sshd.
- status=224/PAM в systemd Код 224/PAM: не удалось открыть сеанс PAM для службы. Обычно нет нужного файла настроек в /etc/pam.d.
- Host key verification failed при подключении к серверу Клиент отказывается подключаться: ключ хоста изменился. Когда это переустановка, а когда повод насторожиться.
- Permission denied в журнале службы Отказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
- sshd: Bad configuration option и отказ запуска sshd не запускается из-за ошибки в sshd_config: неизвестный параметр, устаревшая настройка, ошибка в include.
- sshd: pam_unix и ошибки открытия сеанса Вход по ssh не завершается: ошибки PAM при открытии сеанса. Полный диск, закрытый домашний каталог, ограничения модулей.
- sshd: отказ в подключении из-за MaxStartups Часть подключений отклоняется под нагрузкой: предел незавершённых аутентификаций. Как считать значение.
- sshd: смена порта не действует из-за ssh.socket Порт в sshd_config игнорируется, потому что адрес слушает systemd через сокет-активацию. Где менять порт.
Где встречается чаще всего
Источники
- Документация OpenSSH: MaxAuthTries
-
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено агентом с восемью ключами при MaxAuthTries=6.