Как восстановиться от ошибки “Слишком много неудачных попыток аутентификации для пользователя root”

Я сделал несколько попыток установить SSH-соединение для пользователя root@host с использованием терминала putty. При этом я несколько раз указал неверные учетные данные, а затем указал их правильно, и после того, как учетные данные были приняты, сеанс ssh прерывается с сообщением

“Сервер неожиданно закрыл сетевое соединение”.

Эта ошибка сообщается терминалом putty. При попытке подключения ssh root@localhost из локальной консоли – все работает нормально. Также все работает нормально, когда я подключаюсь к другому пользователю@host с другого хоста. Следовательно, проблемы с сетевым соединением отсутствуют. Единственная ошибка, о которой я думаю: “Слишком много неудачных попыток аутентификации для пользователя root”, хотя putty сообщила об ошибке, отличной от этой.

Вопрос: как восстановиться из этого состояния ошибки и снова позволить putty войти в систему? Перезапуск sshd, похоже, не помогает.

Вы уверены, что вход root по ssh разрешен?

Проверьте sshd_config и убедитесь, что доступ root разрешен. sshd нужно будет перезапустить, если настройки изменятся.

Если вы получаете следующую ошибку SSH:

$ Received disconnect from host: 2: Too many authentication failures for root

Это может произойти, если у вас (по умолчанию на моей системе) хранится пять или более идентификационных файлов DSA/RSA в каталоге .ssh. В этом случае, если опция -i не указана в командной строке, ssh-клиент сначала попытается войти с использованием каждого идентификатора (закрытого ключа), а затем предложит ввести пароль для аутентификации. Тем не менее, sshd разрывает соединение после пяти неудачных попыток входа (по умолчанию это значение может варьироваться).

Таким образом, если у вас есть несколько закрытых ключей в каталоге .ssh, вы можете отключить Public Key Authentication в командной строке, используя необязательный аргумент -o.

Например:

$ ssh -o PubkeyAuthentication=no root@host

“Слишком много неудачных попыток аутентификации для пользователя root” означает, что лимит MaxAuthTries вашего SSH-сервера был превышен. Это происходит, когда ваш клиент пытается аутентифицироваться с помощью всех возможных ключей, хранящихся в /home/USER/.ssh/.

Эта ситуация может быть решена следующими способами:

1. ssh -i /path/to/id_rsa root@host
2. Укажите пару Host/IdentityFile в /home/USER/.ssh/config

Один хост в файле config должен выглядеть примерно так:

Host example.com
  IdentityFile /home/USER/.ssh/id_rsa

Вы также можете установить пользователя, чтобы вам не нужно было вводить его в командной строке, и сократить длинные FQDN, посмотрите этот пример:

host short
  IdentityFile /home/USER/.ssh/id_rsa
  User someuser
  HostName really-long-domain.example.com

Затем подключитесь к серверу really-long-domain.example.com с помощью:

ssh short

Примечание: если вы решите использовать только второй вариант, и попытаетесь использовать ssh example.com, вы все равно получите ошибки (если это то, что привело вас сюда), короткая версия не даст ошибок, вы также можете использовать оба варианта, чтобы иметь возможность ssh [email protected] без ошибок.

3. Увеличьте значение MaxAuthTries на SSH-сервере в /etc/ssh/sshd_config (не рекомендуется).

Для меня эта проблема была решена созданием следующего ssh_config для хоста, к которому я подключался.

(~/.ssh/config)

Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes

Проблема возникла из-за того, что у меня было слишком много ssh-ключей в моем каталоге ~/.ssh, около 16. И без обоих этих директив IdentityFile И IdentitiesOnly в конфигурации, моя машина, по-видимому, пыталась использовать все ключи в ~/.ssh и достигала максимального числа попыток, прежде чем попробовать правильный IdentityFile.

На удаленной машине откройте /etc/sshd_config и измените значение

MaxAuthTries 30

Это типичная проблема, когда вы установили несколько ключей или открыли несколько соединений. Сервер проверяет каждый ключ поэтапно, и если MaxAuthTries установлено на 3, то после первых 3 попыток он отключит вас. Типичная безопасность ssh.

Я предлагаю вам использовать режим подробного вывода во время подключения к удаленной машине для анализа проблемы.

ssh -v -p port_number user@servername

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

Удачи.

Это плохая практика. Просто имейте обычного пользователя на удаленной машине и подключитесь через ssh, используя его, затем получите доступ root с помощью su/sudo.

Чтобы временно решить эту проблему, пока все не будет полностью устранено, как отмечено в другом месте, вы можете сбросить учетную запись PAM пользователя, чтобы он мог попробовать снова:

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>

Я исправил эту проблему в своих системах, выполнив следующие команды:

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

Затем попробуйте ssh на удаленную машину.

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

(Этот совет взят отсюда.)

Я рекомендую вам, как уже упоминалось, использовать другого пользователя, чтобы получить доступ по ssh, а затем использовать команду su, чтобы получить доступ root.

Также убедитесь, что в файле /etc/ssh/sshd_config на сервере включена опция PermitRootLogin.

Я столкнулся с аналогичной проблемой. Однако настоящей причиной было то, что у меня был установлен ForwardAgent yes в конфигурационном файле машины вдоль канала. Я подключался с машины A на машину B на машину C.

Сообщение об ошибке было показано в попытке ssh с B на C, но оно было вызвано тем, что A имел активный пересылочный агент. Таким образом, C сначала получил все ключи от A, а только потом от B.

Это неожиданно возникло, когда я добавил один ключ к A.

Как уже упомянул @sufferer в другом ответе, некоторые дистрибутивы Linux включают мониторы для защиты от атак грубой силы на внешние видимые сервисы, такие как SSH, например DenyHosts или fail2ban. Эти мониторы проверяют журналы на предмет неудачных попыток и добавляют фильтры, чтобы заблокировать IP-адреса, которые имеют слишком много неудач (число настраивается и не зависит от конфигурации sshd).

Если ваш дистрибутив включает fail2ban, который защищает сервисы, добавляя правила в iptables брандмауэр, вы можете проверить, какие сервисы или “тюрьмы” контролируются, используя команду:

sudo fail2ban-client status

Тюрьма для сервиса SSH это sshd, поэтому, чтобы проверить, есть ли забаненные IP, вы можете использовать:

sudo fail2ban-client status sshd

и чтобы разблокировать какой-либо IP a.b.c.d:

sudo fail2ban-client set sshd unbanip a.b.c.d

Если у вас DenyHosts, список заблокированных находится в файле /etc/hosts.deny; вы можете редактировать этот файл напрямую от имени root. Чтобы предоставить некоторому IP a.b.c.d постоянный доступ, вы можете добавить строку sshd:a.b.c.d в файл /etc/hosts.allow.

Как всегда, команда man будет вашим другом:

man fail2ban
man hosts.deny

Должны существовать и другие подобные утилиты, но я использовал только эти.

Обратите внимание, что увеличение количества разрешенных повторных попыток в конфигурации sshd не освобождает заблокированные IP-адреса, а лишь позволяет больше неудач в том же соединении. Если допустимое количество превышено, пользователь/атакующий просто повторно подключается, чтобы попробовать еще несколько раз.

Другие сервисы имеют интегрированный список блокировок (как показано в ответе Раджнеш Такура о перезапуске сервера VNC).

Примечание: если вы используете fail2ban и используете файл jail.local для настройки “тюрем”, добавьте следующее в начало файла, чтобы предотвратить блокировку вашего IP-адреса:

[DEFAULT]
ignoreip = 10.10.1.1 10.0.2.0/24

Перезапустите fail2ban после этого, например, используя systemctl restart fail2ban. Первый IP разрешает один адрес, второй позволяет всем адресам подсети 10.0.2.x; настраивайте по необходимости.

Я решил эту проблему на своем Mac, следуя этим шагам:

1. установив пароль для root с помощью “sudo passwd root”, затем
2. отредактировав и сохранив файл конфигурации ssh с помощью “nano /etc/ssh_config”
   и
3. изменив RSAAuthentication на “no”, а не yes.

Если на вашем сервере все еще включена аутентификация по паролю, вы можете скопировать свой ssh-ключ на него с помощью ssh-copy-id и избежать проблемы Слишком много неудачных попыток аутентификации:

ssh-copy-id -i id_rsa_your_key.pub -p 22 -o PubkeyAuthentication=no username@server

Хорошо, в моем случае это было довольно странно, вот как это было…

У меня стандартная машина vagrant с SSH-ключом, и я могу подключаться к ней с помощью Putty. Пытаясь попасть на нее во время развёртывания в PHPStorm, я получаю ошибку слишком много неудачных попыток аутентификации. Я увеличил значение MaxAuthTries в своем sshd_config, и тогда я получил ошибку Ошибка аутентификации, а затем Отмена аутентификации.

Теперь я не знаю, почему я вообще это попробовал, но… я добавил точку в конце пути к моему SSH-ключу в окне развертывания в PHPStorm. Таким образом, это было так:

C:\Users\Deadpool\\.ssh\chimichanga

а сейчас это выглядит так:

C:\Users\Deadpool\\.ssh\chimichanga.

И это работает… В моей папке “.ssh” у меня есть больше файлов:

chimichanga - копия "id_rsa" с машины vagrant
chimichanga.ppk
chimichanga.pub

Я не уверен, что делает эта чертова точка, но использование файла .ppk не работает, так что, наверное, это какая-то магия 😉 О, и после этого трюка с точкой я смог избавиться от MaxAuthTries.

Другие ответы говорят вам о лучшем способе подключиться как root и о последствиях безопасности этого, но ваш явный вопрос был

как восстановиться из этого состояния ошибки и снова позволить putty войти в систему?

Вы упоминаете в последний раз, что вы подключились, а затем удаленный сервер разорвал соединение.

Что я думаю, так это то, что удаленный сервер работает с fail2ban(*) и он “заблокировал” ваш IP после успешной аутентификации. Вы можете проверить это, попытавшись снова войти, и вы даже не получите приглашение на вход.

Есть два решения: вы можете либо дождаться окончания срока блокировки, после чего все просто вернется в норму, но время блокировки может быть любым. Либо вы можете найти другой компьютер, с которого войдете, сделайте это и “разблокируйте” ваш IP, в этом случае “другой” является с точки зрения удаленного сервера, так что другой компьютер за тем же брандмауэром, вероятно, тоже не сработает.

(*) fail2ban – это супер удобный демон, который может периодически проверять различные журналы и настраивать правила брандмауэра, чтобы сделать сервер “невидимым”, когда он обнаруживает потенциально вредоносное поведение клиента. На Debian он работает “из коробки”, настроенный для обнаружения нескольких неудачных попыток ssh-входа с определенного IP-адреса, и после 3 (я думаю) он отправит все пакеты от этого IP в блокировку. Отменно работает, чтобы остановить эти автоматические, грубой силы атаки.

Nixops отказался предоставить мне ssh-соединения, после выполнения ssh-add -l
я обнаружил, что у меня много ключей в агенте:

ssh-add -l
2048 SHA256:xxxxxxBXXEstjp/OODVNw/WAU/dNv+zu0/IxJZxTUWM /home/jappie/.ssh/id_rsa (RSA)
256 SHA256:xxxxxx+uIS0cAOdJIlRfc0Wild3aodjJY3Fs9j8WplI Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxMMxz5V379R++v7IjZpa+PGFikQ+WBhkN9yRAw Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxM4AJV1AhHL11wifU2o0y4Ky0pSSYlIHOxs+5o Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxjKWr/aJsQj6Cd8Vpe4Zo/7yb2luWSPlzoXaW8 Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxXoZkITGG/pTWkKq0ubXWT/Q3BwtyHWtVY3D8w Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxx3ZMmAXtuPnxX99vJoYr5rydkcRGfWufSFvIDg Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxFR/oD93DohmWdiS1QcwDS0tiJyRqX5uR8I4UE Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxV44yA+DhYHGvDle+i5YarMX3ugY2qUeHV6FKw Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxyoKllIkVQ6MEN2JwuOGHYmrnzSK51piaXSBew Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxlHHHkdH2zuxOSpBNw00c3dBcgonh9BO6dqwRY Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxebuWyWwUj1iiTbSNrb3Gd9Bq0cVOwWtVoKMDU Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxT0IA0ig94WKvhhamWtASQgjSfj2Ad3SDbPGdA Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxr3Hbndz86uSMIBHu/8ZNgPyOrAzpgcSf1JjgY Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxnTspGF7+kVe9/USm/PYUOsfu2kSUK2hG8i9Bc Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxx40Sb4izDy99l0CS5hfy8FYu3IbbyZhHnb6CTk Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxSV+yLE1pbD77sI5QOSf5fAq1Svj4ifGh0KIYU Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxva3zv+mgd22TwPAPTgO4dkrfb4pGMCGJejjyI Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxWmwOyUWdD+UezKDi+mYGcJF5OenFwHmHirv4I Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxeBMCRNiZXA9D8WSXA8zgT9k3wv2UUpbjWhqdo Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxoMN+z3H2yD4GwfoMgLA3i/xWRFZSnygNZGY4k Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxx6J3LYfDQk6koL8Zv6NEJhURllMmYLFffqYVJE Ключ, сгенерированный автоматически NixOps (ED25519)
256 SHA256:xxxxxxfM94iCdSm8Fc2WxIyuqTeKiD9FuyVfvv+ctjA Ключ, сгенерированный автоматически NixOps (ED25519)

ssh-add -D не сработал, конечно. То, что сработало, – это использование gpg-connect-agent напрямую, например gpg-connect-agent 'keyinfo --list' (найдено здесь), что дало мне следующее:

S KEYINFO xxxxxxx2CECE4871B251B5EF291EE7A1841E02DC D - - - C - - -
S KEYINFO xxxxxxxC3F58B90BCF0272E5DF0C0162E5CE6F86 D - - - C - - -
S KEYINFO xxxxxxxB2F4BC9A48FD0948ACF8E57A6D5FEA353 D - - - C - - -
S KEYINFO xxxxxxx060C5B4E738BCEB42E092EC60B3A89F39 D - - - C - - -
S KEYINFO xxxxxxx1D6011780C890257107521213F1A8CF4A D - - - C - - -
S KEYINFO xxxxxxxFAE404870B8F4E53ABC5DD58A8F31F734 D - - - C - - -
S KEYINFO xxxxxxxB8D008C2F0F44DBF7690E7FA0C969D26E D - - - C - - -
S KEYINFO xxxxxxxD14B730225EE367C38C0E1D2796F59B2E D - - - C - - -
S KEYINFO xxxxxxxC2FF3C59717D668DE31E964A4F3CB6390 D - - - C - - -
S KEYINFO xxxxxxx658EA11F094597D1658ACFE91EED1E2C2 D - - - C - - -
S KEYINFO xxxxxxx192F4904A4350A06D299BEC9F1DBD882F D - - - C - - -
S KEYINFO xxxxxxxF5096859B707AFB2D4B0EA8283AEC8350 D - - - C - - -
S KEYINFO xxxxxxxAE3194884396AC27AB8FEDDAFD904868C D - - - C - - -
S KEYINFO xxxxxxxC3FB94F59DF75B09AA6B3C7D8C529AF23 D - - - C - - -
S KEYINFO xxxxxxx8204A609B025706B2420AC24BC0F9CBEE D - - - C - - -
S KEYINFO xxxxxxx00AAC043929D0C5F309B77E947914983A D - - - C - - -
S KEYINFO xxxxxxxA9AC520089E0EF4775824D7F5D981691A D - - - C - - -
S KEYINFO xxxxxxx6D0DDFBF294C0326845EA7A1C9B158A2F D - - - C - - -
S KEYINFO xxxxxxx99CD07C5DE54813BDF6C83F8746D343E7 D - - - C - - -
S KEYINFO xxxxxxx9E5A100363F3E8794F2E6BBA44F63976B D - - - C - - -
S KEYINFO xxxxxxxDCC46D5C998BFD2C3D5A2AF28357C481F D - - - C - - -
S KEYINFO xxxxxxxBB321AB73F242C4EEB48FC73A24AB7EEE D - - - C - - -
S KEYINFO xxxxxxx7F273F322DE256C7A188D50B9B6162047 D - - - C - - -
S KEYINFO xxxxxxxC99A1E0C119C64B6CDACB1B5E56EF4320 D - - - C - - -

что я изменил с помощью vim в команды gpg-connect и просто вставил в pg-connect-agent:

DELETE_KEY --force xxxxxxx2CECE4871B251B5EF291EE7A1841E02DC
DELETE_KEY --force xxxxxxxC3F58B90BCF0272E5DF0C0162E5CE6F86
DELETE_KEY --force xxxxxxxB2F4BC9A48FD0948ACF8E57A6D5FEA353
DELETE_KEY --force xxxxxxx060C5B4E738BCEB42E092EC60B3A89F39
DELETE_KEY --force xxxxxxx1D6011780C890257107521213F1A8CF4A
DELETE_KEY --force xxxxxxxFAE404870B8F4E53ABC5DD58A8F31F734
DELETE_KEY --force xxxxxxxB8D008C2F0F44DBF7690E7FA0C969D26E
DELETE_KEY --force xxxxxxxD14B730225EE367C38C0E1D2796F59B2E
DELETE_KEY --force xxxxxxxC2FF3C59717D668DE31E964A4F3CB6390
DELETE_KEY --force xxxxxxx658EA11F094597D1658ACFE91EED1E2C2
DELETE_KEY --force xxxxxxx192F4904A4350A06D299BEC9F1DBD882F
DELETE_KEY --force xxxxxxxF5096859B707AFB2D4B0EA8283AEC8350
DELETE_KEY --force xxxxxxxAE3194884396AC27AB8FEDDAFD904868C
DELETE_KEY --force xxxxxxxC3FB94F59DF75B09AA6B3C7D8C529AF23
DELETE_KEY --force xxxxxxx8204A609B025706B2420AC24BC0F9CBEE
DELETE_KEY --force xxxxxxx00AAC043929D0C5F309B77E947914983A
DELETE_KEY --force xxxxxxxA9AC520089E0EF4775824D7F5D981691A
DELETE_KEY --force xxxxxxx6D0DDFBF294C0326845EA7A1C9B158A2F
DELETE_KEY --force xxxxxxx99CD07C5DE54813BDF6C83F8746D343E7
DELETE_KEY --force xxxxxxx9E5A100363F3E8794F2E6BBA44F63976B
DELETE_KEY --force xxxxxxxDCC46D5C998BFD2C3D5A2AF28357C481F
DELETE_KEY --force xxxxxxxBB321AB73F242C4EEB48FC73A24AB7EEE
DELETE_KEY --force xxxxxxx7F273F322DE256C7A188D50B9B6162047
DELETE_KEY --force xxxxxxxC99A1E0C119C64B6CDACB1B5E56EF4320
DELETE_KEY --force xxxxxxx6A90DEFE2CBFD47BDB499AD3E8FFD525F
DELETE_KEY --force xxxxxxx12289B276F80910D626D1C09A26995A76
DELETE_KEY --force xxxxxxxF2EAB2BC1F863E364271D5C07D3AB8AF0
DELETE_KEY --force xxxxxxx5B4AC281DEF7EBCF4411FA7CF9A3BDF0B
DELETE_KEY --force xxxxxxx0E10305BAA05252F00A5774CC4EFFE53D
DELETE_KEY --force xxxxxxx9226C5B4F9EB3C595D0E1F579DD3B038C

Проблема решена. Обратите внимание, что я заменил некоторые из подписей на x на случай, если это конфиденциальная информация (я не думаю, что это так, и я их все равно удалил).

Возможно, есть некоторые ошибки sshd, которые необходимо исправить.

Вот один пример, который я испытал:

sshd[2999527]: Аутентификация отклонена: неправильное владение или режимы для каталога /home/user

sshd[2999527]: сообщение повторено 3 раза: [ Аутентификация отклонена: неправильное владение или режимы для каталога /home/user]

Если вы используете разрешенный ключ (ssh-add -L), и разрешения на домашний каталог (например, 770) или файл ~/.ssh/authorized_keys на удаленной машине неправильные (например, слишком широкие), он не сможет вас аутентифицировать из-за ошибок.

Я смог обойти вход, добавив:

Host SOMEHOST
  IdentitiesOnly yes

что по какой-то причине проигнорировало доступ к файлу authorized_keys, и я смог подключиться, используя обычный пароль, чтобы исправить разрешения на каталог с помощью:

sudo chmod 750 /home/$USER

Если это VPS, созданный поставщиком облачных услуг, то это может быть связано с тем, что по умолчанию используется fail2ban. Попробуйте подключиться по SSH с другого IP-адреса (или через веб-портал провайдера, если у них есть интерактивный ssh) и проверьте, был ли ваш IP добавлен в “тюрьму” sshd fail2ban:

Если он находится в блокировке, вы можете разблокировать его с помощью:

Источник: недавно была проблема с новым VPS linode, где несколько неудачных входов пользователя привели к блокировке их IP-адреса для ssh.

У меня была такая же проблема с amazon Ubuntu 22 LTS, позже я обнаружил, что проблема была в pea-gent, попробуйте закрыть его и добавить ключ аутентификации в putty, и вход должен сработать.

Слишком много ssh-ключей в каталоге ~/.ssh может вызвать эту проблему. ssh будет пытаться каждый ключ из указанного каталога и, вероятно, может в конечном итоге совершить слишком много неудачных попыток аутентификации, прежде чем идентифицировать правильный ключ.

Добавление ssh_config, как указано ниже, поможет ssh определить правильный ключ.

(~/.ssh/config)

Host *
  IdentitiesOnly=yes

Иногда это просто вопрос неустановленных корректных прав доступа для закрытого ключа (вздох)

В этом случае, если вы не укажете IdentitiesOnly, как в https://serverfault.com/a/849837/1157968, ssh будет пробовать другие ключи. Это может вызвать “Слишком много неудачных попыток аутентификации для пользователя root”

Таким образом, решение в этом случае:

chmod 600 the-private-key

Я решил эту проблему двумя простыми шагами на своем сервере Ubuntu 16.04 –

Сначала остановить мой сервер vnc или убить процесс –

vncserver -kill :1

а затем снова запустить его –

vncserver

После этого подключитесь к нему с клиентом Remote Desktop –

192.0.2.99:5901

Готово !!

пожалуйста, выполните следующие шаги для решения

1. Создайте резервную копию /etc/ssh/sshd_config
2. Увеличьте значение MaxAuthTries в sshd_config
3. остановите src -s sshd ; запустите src -s sshd

И проверьте снова после вышеуказанных изменений.

У меня была такая же проблема, когда я постоянно получал “Сервер отправил сообщение об отключении типа 2 (ошибка протокола): Слишком много неудачных попыток аутентификации для пользователя”

Я решил эту проблему, удалив все свои ssh (.ppk ключи), а затем вошел в интегрированный сервер AD.