Я сделал несколько попыток установить SSH-соединение для пользователя root @ host с помощью терминала putty. При этом я несколько раз указывал неправильные учетные данные, после чего я указал их правильно, а затем после того, как учетные данные были приняты, сеанс ssh прерывается с
«Сервер неожиданно закрыл сетевое соединение».
Об этой ошибке сообщает терминал шпатлевки. При попытке ssh root @ localhost с локальной консоли - работает нормально. Он также отлично работает, когда я использую ssh otheruser @ host с другого хоста. Так что проблемы с сетевым подключением не виноваты. Единственная ошибка, о которой я думаю: «Слишком много сбоев аутентификации для пользователя root» хотя шпатлевка сообщила о другой ошибке.
Вопрос в том: как выйти из этого состояния ошибки и позволить шпатлевке снова войти в систему? Перезапуск sshd не помогает
«Слишком много сбоев аутентификации для пользователя root» означает, что ваш SSH-сервер Превышен лимит MaxAuthTries. Бывает, что Ваш клиент пытается аутентифицироваться со всеми возможными ключами, хранящимися в /home/USER/.ssh/.
Решить эту ситуацию можно следующими способами:
Host hostIdentityFile /home/USER/.ssh/id_rsaHost host2IdentityFile /home/USER/.ssh/id_rsa2Если вы получили следующую ошибку 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 номер_порта пользователь @ имя_сервера
Гадать, как большинство людей на этом форуме, НЕПРАВИЛЬНО и тратить время впустую. Сначала попробуйте проанализировать проблему, собрать информацию, а затем спросить.
Радоваться, веселиться.
Для меня эта проблема была решена путем создания приведенного ниже 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.
Это плохая практика. Просто установите обычного пользователя на удаленном компьютере и подключитесь через ssh с его помощью, а затем получите root-доступ с помощью su / sudo.
Вы уверены, что вход в ssh с правами root разрешен?
Проверьте sshd_config и убедитесь, что вход в систему root разрешен. Если параметр изменится, необходимо перезапустить sshd.
Я бы порекомендовал вам, как писал выше Анон, использовать другого пользователя для получения доступа по ssh, а затем использовать su команда получить root доступ.
Также не забудьте включить PermitRootLogin в /etc/ssh/sshd_config файл на сервере.
Я тоже столкнулся с той же проблемой. Это легко может произойти, если вы используете Конкурс и иметь в него загружено большое количество ключей, поскольку эти серверы считают каждое предложение открытого ключа попыткой аутентификации.
(Этот совет взят из Вот.)
Чтобы временно решить эту проблему до тех пор, пока все не будет полностью решено, как указано в другом месте, вы можете сбросить подсчет PAM пользователя, чтобы он мог повторить попытку:
pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>
Я исправил эту проблему в своих системах, выполнив следующие команды:
eval $(ssh-agent)
ssh-add ~/.ssh/keyname
Затем попробуйте ssh на удаленной машине
Меня укусила похожая проблема. Однако настоящей причиной было то, что у меня ForwardAgent yes в файле конфигурации машины, расположенной вдоль трубы. Я подключался от машины A к машине B к машине C.
Сообщение об ошибке было показано при попытке ssh от B -> C, но это было вызвано тем, что A активировал пересылку. Итак, сначала C были вручены все ключи от A, и только потом - от B.
Это внезапно появилось, когда я добавил еще один ключ к A.
Я исправил эту проблему на своем Mac:
Как @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-адреса, а только допускает большее количество сбоев в том же соединении. Если разрешенное количество превышено, пользователь / злоумышленник просто повторно подключается снова, чтобы попытаться еще n раз.
В других сервисах был интегрирован список запретов (как показано в ответе Раджнеша Такура о перезапуске сервера VNC).
В других ответах рассказывается, как лучше всего подключиться как root, и о последствиях этого для безопасности, но ваш явный вопрос был
как выйти из этого состояния ошибки и позволить шпатлевке снова войти в систему?
Вы упоминаете, что в последний раз, когда вы подключались, удаленный сервер разорвал соединение.
Я думаю, вы можете обнаружить, что на удаленном сервере работает fail2ban (*), и он "заключил" ваш IP в тюрьму после вашего успешного входа в систему. Вы можете проверить это, попробовав снова войти в систему, и вы даже не получите приглашения на вход.
Есть два решения: вы можете либо переждать время тюремного заключения, после чего все просто вернется в норму, но тюремное заключение может быть любым. Или вы можете найти другой компьютер для входа в систему, сделать это и "освободить" свой IP-адрес, в данном случае "другой" - это с точки зрения удаленного сервера, поэтому другой компьютер за тем же брандмауэром, вероятно, тоже не будет работать. .
(*) fail2ban - очень удобный демон, который может периодически проверять различные файлы журналов и настраивать правила брандмауэра, чтобы сервер «исчезал» при обнаружении потенциально вредоносного поведения со стороны клиента. В debian он изначально настроен на обнаружение нескольких неудачных входов в систему по ssh с определенного IP-адреса, а после 3 (я думаю) он отбрасывает все пакеты с этого IP-адреса. Прекрасно работает, чтобы остановить эти заскриптованные атаки методом грубой силы.
Хорошо, в моем случае это было довольно странно, вот оно ...
У меня есть стандартная бродячая виртуальная машина с ключом 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 после этого "трюка с точками".
Я решил эту проблему двумя простыми шагами на моем сервере Ubuntu 16.04 -
Сначала остановите мой vnc-сервер или убейте процесс -
vncserver -kill :1
а потом снова запустите -
vncserver
После этого подключите его из клиента удаленного рабочего стола -
192.0.2.99:5901
Готово !!
пожалуйста, выполните следующие шаги для разрешения
И проверьте еще раз после вышеуказанных изменений
У меня была та же проблема, когда я продолжал получать «SServer отправил отключенное сообщение типа 2 (ошибка протокола): слишком много ошибок аутентификации для пользователя»
Я решил эту проблему, удалив все мои ssh (ключи .ppk), а затем вошел на интегрированный сервер AD.