SSH Linux (OpenSSH)

SSH в Linux: SSH: клиент выбирает неправильный ключ при наличии нескольких учётных записей

  • Обновлено
  • Чтение ≈ 2 минуты

Краткий ответ

При нескольких SSH-ключах клиент предлагает не тот ключ или сервер закрывает аутентификацию после слишком большого числа попыток. Решение — назначить правильный IdentityFile конкретному Host, не удаляя другие ключи.

В этой статье
  1. Что происходит и когда это важно
  2. Возможные причины и как их отличить
  3. Пошаговая диагностика и исправление
  4. Команды из инструкции с пояснениями
  5. Как проверить результат
  6. Если проблема не устранена

#Что происходит и когда это важно

SSH возвращает Too many authentication failures или Permission denied (publickey), хотя нужный ключ на компьютере существует.

#Возможные причины и как их отличить

Возможная причинаКак узнатьЧто делать
ssh-agent предлагает много ключейКлиент пробует несколько идентификаторов до нужного.В ssh -v много Offering public key.Ограничить IdentitiesOnly для конкретного хоста.
Выбран не тот пользователь или алиасНужный ключ связан с другой учётной записью сервера.Клиент подключается под неправильным User.Указать правильный User в Host.
Нужного ключа нет на сервереДаже выбранный ключ не соответствует authorized_keys.Клиент предлагает ожидаемый ключ, сервер его отклоняет.Проверить публичную часть и авторизацию у администратора.

#Пошаговая диагностика и исправление

  1. Не удаляйте ключи из агентaОткройте терминал на компьютере-клиенте. Если имеются разные серверы/учётные записи, не очищайте ~/.ssh и не используйте временное отключение проверки host key. Сначала выясните, какой ключ нужен конкретному серверу.
  2. Посмотрите имеющиеся публичные ключиВыполните ls -l ~/.ssh/*.pub и ssh-add -l. Вторая команда показывает отпечатки ключей агента, а не содержимое закрытых ключей; если агент недоступен, это не значит, что ключи на диске отсутствуют.
  3. Найдите фактически предлагаемые ключиВыполните ssh -v пользователь@сервер с настоящими именами. Найдите строки Offering public key, Trying private key, Server accepts key. Не публикуйте закрытый ключ, а в отчётах скрывайте имена серверов и пользователей.
  4. Выполните пробный вход только с нужной идентичностьюКогда подтверждён путь к личному закрытому ключу, запустите ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes пользователь@сервер, заменив файл ключа и учётную запись реальными. Опция IdentitiesOnly запрещает использовать лишние идентификаторы из агента, а -i задаёт выбранный файл. Не отправляйте этот файл никому.
  5. Сохраните настройки для конкретного алиасаОткройте ~/.ssh/config текстовым редактором. Создайте блок Host мой-сервер с HostName, User, IdentityFile и IdentitiesOnly yes только для него. Убедитесь, что другие аккаунты имеют собственные блоки и не наследуют чужую настройку.
  6. Проверьте итоговый выборВыполните ssh -G мой-сервер | grep -Ei "^(user|hostname|identityfile|identitiesonly) ". Вывод позволит убедиться в правильном имени и выбранном пути. Затем подключитесь через ssh мой-сервер и проверьте успешный вход.
  7. Отделите отказ сервераЕсли правильный ключ предложен, но не принят, на сервере проверьте его публичную часть в authorized_keys и права по инструкции владельца. Не изменяйте серверную политику MaxAuthTries ради одного клиента. Для отката удалите лишь свой блок Host.

#Команды из инструкции с пояснениями

Linux · Терминал (Bash)Команда
Отпечатки загруженных в агент ключей; без секретных данных.
ssh-add -l
Linux · Терминал (Bash)Команда
Диагностика предложенных клиентом ключей, логин/хост заменить.
ssh -v пользователь@сервер
Linux · Терминал (Bash)Команда
Тест с выбранным личным ключом; путь изменить по факту.
ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes пользователь@сервер

#Как проверить результат

Правильная учётная запись открывается с выбранным ключом, остальные серверы продолжают пользоваться своими ключами.

#Если проблема не устранена

Если нужный ключ не принимается, сравните отпечаток его публичной части с authorised_keys на сервере через администратора; не создавайте новые ключи до выяснения наличия резервных.

SSH: Connection refused на порту 22 — причины и решение Проверьте, запущен ли sshd, и правила файрвола. Linux SSH Linux SSH: Permission denied (publickey) — права authorized_keys — причины и решение Проверьте владельца и права ~/.ssh и authorized_keys. Linux SSH Linux Permission denied (pu… SSH: Permission denied (publickey) — причины и решение `Permission denied (publickey)` означает, что сервер SSH отверг все предложенные клиентом ключи, а другие способы входа (например, пароль) недоступны. Причины: ключ не д… Linux SSH LinuxmacOSWindows SSH: Connection timed out — нет ответа на порту 22 — причины и решение «ssh: connect to host … port 22: Connection timed out» значит, что пакеты до сервера не доходят: закрыт порт файрволом, неверный адрес, не запущен sshd или SSH работает … Linux SSH Linux SSH: Connection refused — соединение отклонено — причины и решение Ошибка ssh: connect to host port 22: Connection refused означает, что на сервере не слушает sshd или порт закрыт файрволом. Проверьте службу sshd, порт, ufw/firewalld, п… Linux SSH Linux

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.