Как восстановить систему после «Слишком много ошибок аутентификации для пользователя root»

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

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

1. ssh - i/path/to/id_rsa root @ Host
2. Укажите Host/IdentityFile пару в / home/USER/.ssh/config.
   • Host host
   • IdentityFile /home/USER/.ssh/id_rsa
   • Host host2
   • IdentityFile /home/USER/.ssh/id_rsa2
3. Увеличьте MaxAuthTries значение на SSH-сервере в / etc/ssh/sshd_config (не рекомендуется).

Если вы получаете следующую ошибку 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 [email protected]

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

MaxAuthTries 30

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

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

ssh -v -p номер_порта user @ имя_сервера

Гадать, как и большинство людей на этом форуме, НЕПРАВИЛЬНО, и это напрасная трата времени. Сначала попробуйте проанализировать проблему, собрать информацию, а затем спросить.

Радоваться, веселиться.

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

(~/.Ssh/конфигурации)

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

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

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

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

(Этот совет взят из здесь .)

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

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

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

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

Затем пытается SSH в удаленной машине

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

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

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

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

Это внезапно появилось, когда я добавил еще один ключ к А.

Я исправил эту проблему на своем Mac:

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

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

как восстановить эту ошибку и разрешить PuTTY войти снова?

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

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

Есть два решения, вы можете либо подождать время тюремного заключения, после чего все просто нормализуется, но время тюремного заключения может быть любым. Или вы можете найти другой компьютер для входа, сделать это и "разблокировать" ваш IP, в этом случае "другой" - это точка зрения удаленного сервера, так что другой компьютер за тем же брандмауэром, вероятно, тоже не будет работать ,.

(*) fail2ban - это супер удобный демон, который может периодически проверять различные файлы журналов и корректировать правила брандмауэра, чтобы сервер "исчезал" при обнаружении потенциально вредоносного поведения от клиента. В debian он выходит из коробки, настроенной на обнаружение нескольких неудачных входов в систему ssh с определенного IP, и после 3 (я думаю) он отбросит все пакеты с этого IP. Работает блестяще, чтобы остановить эти скриптовые атаки грубой силы.

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

Сначала остановите мой VNC-сервер или убейте процесс -

vncserver -kill :1

и затем начните это снова -

vncserver

После этого подключите его из клиента удаленного рабочего стола -

999.99.99.99:5901

Выполнено !!

Итак, в моем случае это было довольно странно, вот так ...

У меня есть стандартный vagrant VM с ключом SSH, и я могу подключиться к нему по SSH с помощью PuTTY. При попытке получить его во время развертывания в PHPStorm я получаю too many authentication failures ошибка. Поэтому я увеличил MaxAuthTries в моем sshd_config а потом меня ударили Auth failed ошибка, а затем Auth cancel.

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

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

и теперь это так:

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

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

chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub

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

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

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

Sudo fail2ban-client status

Jail для службы 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-адреса, а только разрешает больше сбоев в том же соединении. Если допустимое число превышено, пользователь/злоумышленник просто переподключается, чтобы попытаться еще n раз.

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