Ошибка SSH Too many authentication failures: слишком много ключей

Что сделать прямо сейчас

1. Подключитесь, указав ключ явно: ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@ВАШ_IP.
2. Если входите по паролю, запретите попытки по ключам: ssh -o PubkeyAuthentication=no root@ВАШ_IP.
3. Чтобы не набирать это каждый раз, пропишите ключ в файле config.

Команды для Windows и подробности — в шагах ниже. Если после нескольких попыток сервер вообще перестал отвечать, см. раздел «Если сервер перестал отвечать после попыток».

Вместо ВАШ_IP подставьте адрес своего сервера из панели провайдера. В примерах вывода стоит адрес 203.0.113.10 — у вас будет свой IP.

Что значит эта ошибка

Полностью сообщение выглядит так:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22

При входе ssh по очереди предлагает серверу ключи. Каждый ключ, который не подошёл, сервер считает неудачной попыткой. Сколько попыток даётся на одно подключение, задаёт настройка сервера MaxAuthTries, по умолчанию 6. Когда попытки кончаются, сервер разрывает подключение.

Откуда у ssh столько ключей: он берёт ключи, которые держит программа ssh-agent, и файлы со стандартными именами в папке .ssh — id_rsa, id_ecdsa, id_ed25519 и другие. Ключи из агента ssh предлагает первыми. Ключ, указанный через -i, если его нет в агенте, идёт после них. Поэтому одного -i бывает мало — нужен ещё параметр IdentitiesOnly.

Шаг 1. Укажите ключ явно

На Mac и Linux:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@ВАШ_IP

Команды для Windows ниже — для «Командной строки»: нажмите Win+R, напечатайте cmd и нажмите Enter (подробнее). Если строка в окне начинается с PS, это PowerShell: напечатайте cmd, нажмите Enter и продолжайте в том же окне.

ssh -i "%USERPROFILE%\.ssh\id_ed25519" -o IdentitiesOnly=yes root@ВАШ_IP

-i задаёт файл закрытого ключа — без .pub на конце. IdentitiesOnly=yes запрещает ssh предлагать серверу другие ключи, в том числе из агента. Если ваш ключ называется иначе, подставьте своё имя файла.

Если вход прошёл, причина была в лишних ключах. Если теперь появилось Permission denied (publickey), этот ключ серверу незнаком — см. Permission denied (publickey).

Шаг 2. Пропишите ключ в файле config

Чтобы не писать параметры каждый раз, добавьте сервер в файл config в папке .ssh (как создать этот файл):

Host myvps
    HostName 203.0.113.10
    User root
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Вместо 203.0.113.10 впишите IP своего сервера. Теперь подключение — короткая команда ssh myvps, и ssh предложит серверу только этот ключ.

Шаг 3. Уберите лишние ключи из ssh-agent

Посмотрите, какие ключи держит агент. Команда одна для Mac, Linux и Windows:

ssh-add -l

Каждая строка — один ключ: длина, отпечаток SHA256:…, подпись и тип в скобках. Если строк много, а нужен один ключ, очистите агент и добавьте только нужный. На Mac и Linux:

ssh-add -D
ssh-add ~/.ssh/id_ed25519

В «Командной строке» Windows вторая команда — ssh-add "%USERPROFILE%\.ssh\id_ed25519".

Первая команда ответит All identities removed., вторая — примерно так:

Identity added: /Users/anna/.ssh/id_ed25519 (anna@MacBook-Air)

Сами файлы ключей при этом не удаляются: ssh-add -D только убирает ключи из памяти агента. Если ssh-add -l отвечает The agent has no identities., агент пуст — лишние ключи берутся из папки .ssh, и помогут шаги 1 и 2.

В Windows служба ssh-agent бывает выключена — тогда ssh-add ответит ошибкой. Значит, агент ключей не держит и дело не в нём: используйте шаг 1 или 2.

Шаг 4. Если входите по паролю

Если сервер пускает по паролю, а ключа для него у вас нет, запретите ssh пробовать ключи. Команда одинаковая для всех систем:

ssh -o PubkeyAuthentication=no root@ВАШ_IP

ssh сразу перейдёт к паролю. Чтобы не набирать это каждый раз, добавьте строку PubkeyAuthentication no в блок этого сервера в файле config.

Если сервер перестал отвечать после попыток

Сервер SSH версии 9.8 и новее после неудачных подключений может на время перестать принимать подключения с вашего IP. Так работает защита PerSourcePenalties, она включена по умолчанию, и по умолчанию такая блокировка длится не дольше 10 минут.

Пока блокировка действует, ssh выдаёт уже другую ошибку: подключение обрывается в самом начале, а в сообщении есть слова kex_exchange_identification или Connection closed. Разбор — на странице kex_exchange_identification.

Подождите 10 минут и подключайтесь сразу командой из шага 1, чтобы не накопить новые неудачи. В Ubuntu 24.04 сервер SSH версии 9.6 — такой защиты в нём нет.

Как проверить

Подключитесь с ключом из шага 1 или по короткому имени из шага 2 с подробным отчётом:

ssh -v myvps

В отчёте должна быть одна строка Offering public key — с нужным ключом, — а в конце:

Authenticated to 203.0.113.10 ([203.0.113.10]:22) using "publickey".

Похожие ошибки

Источники

• man ssh_config — IdentityFile, IdentitiesOnly и PubkeyAuthentication.
• man sshd_config — MaxAuthTries и PerSourcePenalties.
• man ssh-add — параметры -l и -D.
• OpenSSH 9.8: список изменений — PerSourcePenalties.
• Пакет openssh-server в Ubuntu 24.04 — версия 9.6.
• Исходный код OpenSSH — порядок, в котором ssh предлагает ключи.

Сверено 9 октября 2026 года.

Что почитать дальше

• Короткое имя вместо IP: файл config — как устроен файл config.
• Permission denied (publickey) — если сервер не принимает ключ.
• kex_exchange_identification — если сервер обрывает подключение сразу.
• Как подключиться к VPS по SSH — вход по ключу с нуля.