ssh_exchange_identification: чтение: сброс соединения по пиру

107

Я на OS X пытаюсь SSH на сервере Ubuntu 12.04. Я был в состоянии SSH в - пока внезапно вещи не перестали работать. Я читал в Интернете, чтобы использовать -vдля отладки. Вывод показан ниже. Если я ssh в другой ящик, а затем ssh из этого ящика на сервер, я могу войти в систему. Я не знаю, как отладить эту проблему, но хотел бы узнать.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

До сих пор (по совету досок объявлений) я искал файл отказа хостов - но на моей машине такого файла нет.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

У меня есть доступ администратора на клиентском компьютере, но не на сервере.

ssh

— bernie2436
источник

Я бы порекомендовал начать sshdпрослушивание на альтернативном порте с подробным выводом и предоставить вывод при попытке подключения к нему. $(which sshd) -d -p 23, Если у вас нет возможности сделать это, ваши возможности довольно ограничены. Лучше всего получить кого-то, кто имеет права администратора на сервере.

— Патрик

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

— MDPC

12

Файл hosts.deny и hosts.allow следует проверять на сервере , а не на клиенте. Кроме того, системные журналы на сервере должны быть проверены. Если у вас нет доступа к ним, вы можете обратиться к администратору сервера, чтобы посмотреть.

— ckujau

Вы нашли решение для этого? в чем была проблема?

— МэВ

2

Был список hosts.deny, который был заполнен администратором с помощью автоматического скрипта. Поскольку в какой-то момент я забыл свой пароль, у меня было несколько неудачных попыток войти в систему, когда мой IP был добавлен в список hosts.deny. Так много для продуктивности чрезмерной безопасности.

— К.-Майкл Ай

25

Резкое изменение может быть результатом изменения файла конфигурации в sshdконфигурации серверов , но вы указываете, что не можете проверить или изменить это без права администратора. Вы все еще можете попробовать следующее, если администраторы сервера не могут быть достигнуты (вовремя).

В вашем журнале указывается только строка локальной версии, вам следует проверить версии sshdзапущенных на сервере и на промежуточном компьютере.

Если эти версии отличаются (особенно между локальным компьютером и сервером и менее между промежуточной машиной и сервером) там может быть некоторые переговоры несовместимость, это уже случалось раньше в ssh. Раньше решением было сократить количество записей Ciphers, HostKeyAlgorithms и / или MAC-адресов, либо в командной строке ( ssh -c aes256-ctrи т. Д.) , Либо в вашей /etc/ssh/ssh_config.

Вы должны посмотреть в отладочной информации (от подключения через промежуточное соединение к серверу) соответствующие значения в качестве аргумента для командной строки -c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmsи -m/ MACsсоответственно. изменения ssh_config.

У меня не было этой проблемы некоторое время, но когда мне это удалось, IIRC было достаточно, чтобы вручную настроить параметр Ciphers и HostKeyAlgorithms, после чего я мог обновить sshdверсию сервера, и проблема исчезла.

— Энтон
источник

3

В моем случае серверный sshdпакет был обновлен до более новой версии, что привело к несовместимости с моей текущей sshконфигурацией клиента, как вы сказали. Очистка моих старых sshфайлов конфигурации сделала свое дело. Это должен быть принятый ответ.

— Чакрит

2

@chakrit как вы очистили свои старые конфигурационные файлы ssh?

— Джонатан

@Jonathan Я установил диск восстановления, чтобы сделать это.

— чакрит

16

Возможно, вы были забанены fail2banили denyhosts. В таком случае (а также чтобы проверить это), если вы не хотите беспокоиться о помощи поставщика вашего сервера, вам необходимо войти на свой сервер с другого IP-адреса: например, с другого сервера, домашнего соединения друга или Wi-Fi горячая точка или использование SSH с TOR.

После входа убедитесь, что ваш IP-адрес действительно отображается в /etc/hosts.deny(на стороне сервера). Если так, то fail2banили denyhostsдействительно должен быть виновником.

См. Ответы на этот вопрос, чтобы узнать, как предотвратить постоянную denyhostsблокировку вашего адреса. Для того, чтобы fail2banнайти свой ip с iptables -L --line-numberи отменить запретiptables -D <chain> <chain number> на ip , проверьте подробности о howtoforge .

Вы можете добавить свой IP-адрес fail2banи denyhostsбелый список (соответственно /etc/fail2ban/jail.conf, строку ignoreipи /var/lib/denyhosts/allowed-hosts, при необходимости, создать его (но помните, что путь может отличаться в вашем дистрибутиве)), чтобы предотвратить повторение проблемы.

— Скиппи ле Гран Гуру
источник

9

На хост-сервере удалите ssh pub.key, расположенный здесь: ~/.ssh/authorized_keysдля вашего Mac. Затем, tail -f /var/log/auth.logпока вы открываете другой терминал и снова пытаетесь выполнить ssh ssh -v me@server. Если у вас запросили пароль, значит, проблема с вашим ключом ssh. Если вы все еще видите ответ «ssh_exchange_identification: read: Connection reset by peer», то вы сможете определить причину проблемы из записи журнала в файле «/var/log/auth.log» после неудачной попытки. чтобы залогиниться.

Если вам все еще не удалось подключиться, опубликуйте запись из файла аутентификации здесь, и я пересмотрю свой ответ.

— devnull
источник

Нет необходимости удалять ключ SSH в некоторых случаях. Перейдите прямо к tail -f /var/log/auth.log и проверьте последние попытки.

— Джек Робсон,

6

Это может произойти, если у вас есть несколько машин в сети с одним и тем же MAC-адресом (например, если вы делаете копию виртуальной машины и забыли сменить MAC).

— elCapitano
источник

4

Я получил это из-за имен серверов моего интернет-провайдера /etc/resolv.conf. Эти серверы имен часто перегружены, и в случае сбоя обратного просмотра DNS соединение sshdбудет разорвано. Я решил проблему с помощью более надежных серверов имен, например 8.8.8.8.

— njahnke
источник

4

Я столкнулся с той же проблемой. Я бы успешно открыл сессию SSH, но через некоторое время он был бы сброшен. Когда я сразу пытался подключить усиление, я получал ошибку «Соединение отказано». когда я отлаживал сеанс, я получил это сообщение в то время, когда соединение сбрасывалось

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1

В этот момент я понял, что в сети возник конфликт IP-адресов. Я перешел на другой адрес и проблема была решена

— Дэвид
источник

2

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

— Пизис

@Pysis: правильный ответ с поправкой

— Даниил

3

Ваш журнал означает, что на стороне сервера разрывается соединение. Чтобы выяснить причину, вы должны обратиться к журналам на стороне сервера, в них должна быть указана причина отключения. Вы почти всегда сможете найти логи в / var / log / messages

Я мог предположить, что, поскольку соединение разорвалось сразу после того, как клиент отправил номер версии, сервер каким-то образом объявил клиента несовместимым

— gena2x
источник

3

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

На более новых версиях sshприведена ошибка Connection refusedили Bad port.

В более старых версиях приведена ошибка ssh_exchange_identification: read: Connection reset by peer

Поэтому, когда вы получаете такую ошибку, проверьте правильность порта.

— Мугома Дж. Окомба
источник

1

Я знаю, что этот вопрос старый, но я хотел поделиться некоторыми результатами, которые у меня были. Проверьте, есть ли /var/empty/sshdна сервере соответствующие владельцы и разрешения.

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

— Эндрю Боерема
источник

1

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

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

Примерами таких политик грубой силы из случайной выборки поставщиков являются:

— Джефф Шаллер
источник