☰

ssh_exchange_identification: Соединение закрыто удаленным хостом (без использования hosts.deny)

tag-icon • tag-icon linux ssh key-authentication
ssh_exchange_identification: Соединение закрыто удаленным хостом (без использования hosts.deny)

Янетпри использовании hosts.allowили hosts.deny, кроме того, SSH работает с моей машины с Windows (тот же ноутбук, другой жесткий диск), но не с моей машины с Linux.

ssh -vvv root@host -p portдает:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer

На машине с Windows все работает нормально, поэтому я проверил журналы безопасности, и строки в них идентичны, сервер обрабатывает две разные «машины» одинаково, и им обем разрешен доступ через аутентификацию с открытым ключом.

Из этого следует вывод, что проблема, должно быть, в моем локальном ноутбуке с ArchLinux... но в чем именно?

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$

Так что проблема не в этом...

[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Конфликтов с настройками брандмауэра нет (на данный момент).

[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------  2 torxed users 4096 Sep  3  2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw-------  1 torxed users 1679 Sep  3  2013 id_rsa
-rw-r--r--  1 torxed users  403 Sep  3  2013 id_rsa.pub
-rw-r--r--  1 torxed users  170 May 11 11:21 known_hosts

Разрешения, похоже, в порядке (на сервере то же самое). Также пробовал без настройки, но /etc/ssh/ssh_configрезультат тот же, за исключением большого количества автоматической настройки, происходящей в клиенте, которая заканчивается той же ошибкой.

решение1

Первоначально опубликовано на Ask Ubuntu

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

Поиск неисправностейsshd

Что я нахожу вообще очень полезным в таких случаях, так это начинать, sshdне давая ему демонизироваться. Проблема в моем случае была в том, что ни то, ни syslogдругое не auth.logпоказало ничего значимого.

Когда я запустил его из терминала, я получил:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Гораздо лучше! Это сообщение об ошибке позволило мне увидеть, что не так, и исправить это. Ни один из файлов журнала не содержал этого вывода.

Примечание:по крайней мере в Ubuntu это $(which sshd)лучший способ удовлетворить sshdтребование абсолютного пути. В противном случае вы получите следующую ошибку: sshd re-exec requires execution with an absolute path. The -p 10222делает sshdпрослушивание на этом альтернативном порту, переопределяя файл конфигурации - это для того, чтобы он не конфликтовал с потенциально запущенными sshdэкземплярами. Убедитесь, что выбрали здесь свободный порт.

Наконец: подключитесь к альтернативному порту ( ssh -p 10222 user@server).

Этот метод помог мне много-много раз в поиске проблем, будь то проблемы аутентификации или другие типы. Чтобы получить действительно подробный вывод в stdout, используйте $(which sshd) -Ddddp 10222(обратите внимание на добавленный ddдля увеличения многословности). Для большей отладки проверьте качество man sshd.

Главное преимущество этого метода в том, что он позволяет проверить sshdконфигурациюбезнеобходимо перезапустить sshdпорт по умолчанию.Обычноэто не должно мешать существующим SSH-соединениям, но я это видел. Так что это позволяет проверить файл конфигурации до того, как - потенциально - отрезать доступ к удаленному серверу (например, у меня это есть для некоторых VPS и даже для физических серверов, где мне нужно доплачивать, чтобы получить внеполосный доступ к машине).

решение2

У вас также может быть хост, память которого настолько сильно фрагментирована, что он не может выделить страницу непрерывной памяти для разветвления процесса для хостинга сеанса SSH.

В таком случае вы можете получить одно из сообщений:

ssh_exchange_identification: read: Connection reset by peer

или:

Connection closed by aaa.bbb.ccc.ddd

в зависимости от того, как далеко зайдет хозяин, прежде чем он выпрыгнет.

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

решение3

На всякий случай, потому что это случилось со мной. Убедитесь, что у вас запущен sshd на хосте!

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

решение4

Я столкнулся с ssh_exchange_identification: read: Connection reset by peerпроблемой в скрипте, который запускает 16 или более сеансов ssh в цикле. sshd, по-видимому, не справляется; добавление короткого сна (очевидно,обходной путь... :D (противоположники) решили мою проблему:

for i in $(seq 32)
do
    ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
    # for > 8 connections, ssh has ssh_exchange_identification issues
    sleep 0.1
done

Связанный контент