Я сделал несколько попыток установить SSH-соединение для пользователя root @ Host с помощью терминала PuTTY. При этом я несколько раз указывал неправильные учетные данные, и после этого я их правильно указал, а затем, после того как учетные данные были приняты, сеанс ssh прерывается с
"Сервер неожиданно закрыл сетевое соединение".
Об этой ошибке сообщает терминал PuTTY. При попытке ssh root @ localhost с локальной консоли - работает нормально. Это также хорошо работает, когда я ssh otheruser @ Host с другого хоста. Так что проблемы с сетевым подключением не виноваты. Единственная ошибка, о которой я думаю, это: "Слишком много ошибок аутентификации для пользователя root" , хотя PuTTY сообщил о другой ошибке.
Вопрос заключается в следующем: как исправить ошибку и разрешить PuTTY войти снова? Перезапуск sshd, похоже, не помогает
Вы уверены, что вход в систему root по ssh разрешен?
Проверьте sshd_config и убедитесь, что вход в систему root разрешен. sshd нужно будет перезапустить, если настройка изменится.
"Слишком много сбоев аутентификации для пользователя root" означает, что ваш сервер SSH превышен предел MaxAuthTries. Случается так, что Ваш клиент пытается аутентифицироваться всеми возможными ключами, хранящимися в /home/USER/.ssh/.
Эту ситуацию можно решить следующими способами:
Host host
IdentityFile /home/USER/.ssh/id_rsa
Host host2
IdentityFile /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 [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:
Другие ответы сообщают вам лучший способ подключения с правами 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).