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

<p>я сделал несколько попыток установить ssh-соединение для пользователя root @ host с помощью терминала putty. при этом я несколько раз указывал неправильные учетные данные, и после этого я их правильно указал, а затем, после того как учетные данные были приняты, сеанс ssh прерывается с</p><blockquote> <p>"сервер неожиданно закрыл сетевое соединение".</p> </blockquote><p>об этой ошибке сообщает терминал putty. при попытке ssh root @ localhost с локальной консоли - работает нормально. это также хорошо работает, когда я ssh otheruser @ host с другого хоста. так что проблемы с сетевым подключением не виноваты. единственная ошибка, о которой я думаю, это: <em> "слишком много ошибок аутентификации для пользователя root" </em>, хотя putty сообщил о другой ошибке.</p><p>вопрос заключается в следующем: <strong>как исправить ошибку и разрешить putty войти снова?</strong> перезапуск sshd, похоже, не помогает</p>

<p>вы уверены, что вход в систему root по ssh разрешен?</p><p>проверьте sshd\_config и убедитесь, что вход в систему root разрешен. sshd нужно будет перезапустить, если настройка изменится.</p>

<p>"слишком много сбоев аутентификации для пользователя root" означает, что ваш сервер ssh <strong>превышен предел maxauthtries</strong>. случается так, что ваш клиент пытается аутентифицироваться всеми возможными ключами, хранящимися в /home/user/.ssh/.</p><p>эту ситуацию можно решить следующими способами:</p><ol> <li>ssh <strong>- i/path/to/id\_rsa</strong> root @ host</li> <li>укажите <strong>host/identityfile</strong> пару в <strong>/ home/user/.ssh/config</strong>. <ul> <li><code>host host</code></li> <li><code>identityfile /home/user/.ssh/id\_rsa</code></li> <li><code>host host2</code></li> <li><code>identityfile /home/user/.ssh/id\_rsa2</code></li> </ul> </li> <li>увеличьте <strong>maxauthtries</strong> значение на ssh-сервере в <strong>/ etc/ssh/sshd\_config</strong> (не рекомендуется).</li> </ol>

<p>если вы получаете следующую ошибку ssh:</p><pre><code>$ 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 </code></pre>

<p>на удаленной машине откройте/etc/sshd\_config и измените значение</p><blockquote> <p>maxauthtries 30</p> </blockquote><p>это типичная проблема, когда вы установили несколько ключей или открыли несколько подключений. сервер проверяет шаг за шагом каждый ключ, и если maxauthtries настроен на 3, то после первых 3-х попыток вы отключите вас. типичная безопасность ssh.</p><p>я предлагаю вам использовать подробный режим при подключении к удаленной машине для анализа проблемы.</p><blockquote> <p>ssh -v -p номер\_порта user @ имя\_сервера</p> </blockquote><p>гадать, как и большинство людей на этом форуме, неправильно, и это напрасная трата времени. сначала попробуйте проанализировать проблему, собрать информацию, а затем спросить.</p><p>радоваться, веселиться.</p>

<p>для меня эта проблема была решена путем создания приведенного ниже ssh\_config для хоста, к которому я подключался.</p><p>(~/.ssh/конфигурации)</p><pre><code>host example hostname example.com user admin identityfile ~/path/to/ssh\_key\_rsa identitiesonly=yes </code></pre><p>проблема возникла из-за того, что в моей папке <code>~/.ssh</code> слишком много ключей ssh, например, 16 или около того. и без обеих этих директив <code>identityfile</code> and <code>identitiesonly</code> в конфигурации мой компьютер, по-видимому, пробовал все ключи в <code>~/.ssh</code> и достиг максимального числа попыток, прежде чем пытаться выполнить правильный identityfile.</p>

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

<p>я также столкнулся с той же проблемой. это может легко произойти, если вы используете <strong> pageant </strong> и в него загружено <strong> большое количество ключей </strong>, поскольку эти серверы считают каждое предложение открытого ключа попыткой аутентификации.</p><p>(этот совет взят из <a href="https://winscp.net/eng/docs/message\_too\_many\_authentication\_failures">здесь</a> .)</p>

<p>как я уже писал выше, я бы порекомендовал вам использовать другого пользователя для получения доступа по ssh, а затем использовать команду <code>su</code> для получения доступа к <code>root</code>.</p><p>также обязательно включите <code>permitrootlogin</code> в <code>/etc/ssh/sshd\_config</code> файл на сервере.</p>

<p>я исправил эту проблему в своих системах, выполнив следующие команды:</p><pre><code>eval $(ssh-agent) ssh-add ~/.ssh/keyname </code></pre><p>затем пытается ssh в удаленной машине</p>

<p>чтобы временно решить эту проблему, пока все не будет полностью решено, как отмечено в другом месте, вы можете сбросить счетчик pam пользователя, чтобы он мог повторить попытку:</p><pre><code>pam\_tally --reset --user <username> pam\_tally2 --reset --user <username> </code></pre>

<p>я был укушен подобной проблемой. однако настоящей причиной было то, что у меня было <code>forwardagent yes</code> в файле конфигурации машины вдоль трубы. я подключался от машины a к машине b к машине c.</p><p>сообщение об ошибке было показано при попытке ssh от b -> c, но оно было вызвано тем, что a имела активную пересылку. таким образом, c сначала вручил все ключи от a, и только потом ключи от b.</p><p>это внезапно появилось, когда я добавил еще один ключ к а.</p>

<p>я исправил эту проблему на своем mac:</p><ol> <li>установка пароля root с помощью "sudo passwd root" затем</li> <li>редактирование и сохранение конфигурационного файла ssh с помощью "nano/etc/ssh\_config" и</li> <li>изменив rsaauthentication на "нет", а не на "да".</li> </ol>

<p>другие ответы сообщают вам лучший способ подключения с правами root и последствия этого для безопасности, но ваш явный вопрос был</p><blockquote> <p>как восстановить эту ошибку и разрешить putty войти снова?</p> </blockquote><p>вы упомянули в последний раз, когда вы подключились, тогда удаленный сервер оборвал соединение.</p><p>я думаю, вы можете обнаружить, что на удаленном сервере работает fail2ban (*), и он "заключил в тюрьму" ваш ip после успешного входа в систему. вы можете проверить это, попытавшись войти снова, и вы даже не получите приглашение для входа.</p><p>есть два решения, вы можете либо подождать время тюремного заключения, после чего все просто нормализуется, но время тюремного заключения может быть любым. или вы можете найти другой компьютер для входа, сделать это и "разблокировать" ваш ip, в этом случае "другой" - это точка зрения удаленного сервера, так что другой компьютер за тем же брандмауэром, вероятно, тоже не будет работать ,.</p><p>(*) fail2ban - это супер удобный демон, который может периодически проверять различные файлы журналов и корректировать правила брандмауэра, чтобы сервер "исчезал" при обнаружении потенциально вредоносного поведения от клиента. в debian он выходит из коробки, настроенной на обнаружение нескольких неудачных входов в систему ssh с определенного ip, и после 3 (я думаю) он отбросит все пакеты с этого ip. работает блестяще, чтобы остановить эти скриптовые атаки грубой силы.</p>

<p>я решил эту проблему двумя простыми шагами на моем сервере ubuntu 16.04 -</p><p>сначала остановите мой vnc-сервер или убейте процесс -</p><pre><code>vncserver -kill :1 </code></pre><p>и затем начните это снова -</p><pre><code>vncserver </code></pre><p>после этого подключите его из клиента удаленного рабочего стола -</p><pre><code>999.99.99.99:5901 </code></pre><p>выполнено !!</p>

<p>итак, в моем случае это было довольно странно, вот так ...</p><p>у меня есть стандартный vagrant vm с ключом ssh, и я могу подключиться к нему по ssh с помощью putty. при попытке получить его во время развертывания в phpstorm я получаю <code>too many authentication failures</code> ошибка. поэтому я увеличил <code>maxauthtries</code> в моем <code>sshd\_config</code> а потом меня ударили <code>auth failed</code> ошибка, а затем <code>auth cancel</code>.</p><p>теперь я не знаю точно, почему я даже попытался это сделать, но ... я добавил точку в конце пути моего ключа ssh в окне развертывания в phpstorm. так было так:</p><pre><code>c:\users\deadpool\\.ssh\chimichanga </code></pre><p>и теперь это так:</p><pre><code>c:\users\deadpool\\.ssh\chimichanga. </code></pre><p>и это работает ... в моей папке ".ssh" у меня есть больше файлов:</p><pre><code>chimichanga - copy of "id\_rsa" from vagrant machine chimichanga.ppk chimichanga.pub </code></pre><p>я не уверен, что делает эта чертова точка, но используя <code>.ppk</code> файл не работает, поэтому я думаю, что это своего рода волшебство;) о, и я мог бы избавиться от maxauthtries после этого "точечного трюка".</p>

<p>как @sufferer упомянул в другом ответе, некоторые дистрибутивы linux включают мониторы для защиты от атак грубой силы на внешние видимые сервисы, такие как ssh, например <code>denyhosts</code> или <code>fail2ban</code>. эти мониторы проверяют файлы журналов в поисках неудачных попыток и добавляют фильтры для блокировки ip-адресов, на которых слишком много сбоев (число настраивается и не зависит от конфигурации sshd).</p><p>если ваш дистрибутив включает <code>fail2ban</code>, которые защищают службы, добавляющие правила в брандмауэр iptables, вы можете проверить, какие службы или "тюрьмы" контролируются с помощью команды:</p><pre><code>sudo fail2ban-client status </code></pre><p>jail для службы ssh - sshd, поэтому для проверки наличия заблокированных ip-адресов вы можете использовать:</p><pre><code>sudo fail2ban-client status sshd </code></pre><p>и разблокировать некоторые ip a.b.c.d:</p><pre><code>sudo fail2ban-client set sshd unbanip a.b.c.d </code></pre><p>если у вас есть <code>denyhosts</code>, список запрещенных находится в файле /etc/hosts.deny; вы можете редактировать этот файл напрямую как root. чтобы предоставить некоторый постоянный доступ к ip a.b.c.d, вы можете добавить строку <code>sshd:a.b.c.d</code> в файл /etc/hosts.allow.</p><p>как всегда, команда <code>man</code> - ваш друг:</p><pre><code>man fail2ban man hosts.deny </code></pre><p>должны существовать другие подобные утилиты, но я только использовал их.</p><p>обратите внимание, что увеличение числа повторных попыток, разрешенных в конфигурации sshd, не освобождает заблокированные ip-адреса, а только разрешает больше сбоев в том же соединении. если допустимое число превышено, пользователь/злоумышленник просто переподключается, чтобы попытаться еще n раз.</p><p>другие сервисы имели встроенный список запретов (как показано в ответе раджнеш тхакур о перезапуске сервера vnc).</p>