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

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

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

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

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

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

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

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

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

1. ssh -i / путь / к / 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 root@host

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

MaxAuthTries 30

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

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

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

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

Веселиться.

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

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

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

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

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

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

Кроме того , убедитесь , чтобы включить PermitRootLoginв /etc/ssh/sshd_configфайл на сервере.

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

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

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

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 на «нет», а не на «да».

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

У меня есть стандартная бродячая виртуальная машина с ключом 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 после этого "точечного трюка".

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

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

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

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

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

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

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

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

sudo fail2ban-client status

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

sudo fail2ban-client status sshd

и разблокировать какой-нибудь IP abcd:

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

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

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

man fail2ban
man hosts.deny

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

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

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

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

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

vncserver -kill :1

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

vncserver

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

192.0.2.99:5901

Готово !!

пожалуйста, следуйте инструкциям ниже для разрешения

1. Резервное копирование / etc / ssh / sshd_config
2. Увеличьте значение MaxAuthTries в sshd_config
3. stoprc -s sshd; startrc -s sshd

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

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

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