Проблема с SSH - Сбой чтения из сокета: Сброс соединения по пиру

23

Я могу SSH в одном направлении без проблем:

ХОРОШО:

ssh user@computerA

но с другой стороны

ssh user@computerB

Я получаю Read from socket failed: Connection reset by peer.

Я даже не начинаю знать, где искать, чтобы решить это.

У кого-нибудь есть подсказки?

ssh

— boehj
источник

Какая у вас конфигурация сети? Есть ли какая-либо машина за брандмауэром / маршрутизатором?

— NorTicUs

Оба просто подключены друг к другу через кабель Ethernet через маршрутизатор. В прошлом у них был SSH в обоих направлениях.

— Boehj

Вы проверяли, работают ли оба демона SSH? Что-нибудь в логах?

— NorTicUs

Хорошие и плохие новости: я ответил на свой вопрос. Я напишу это ниже. Спасибо за вашу помощь все равно.

— Boehj

13

начать мониторинг файла журнала сервера

tail -f /var/log/auth.log
добавить -v, чтобы получить подробный вывод на стороне клиента

ssh user@computerB -v

Это может дать вам более подробную информацию о причине. если на сервере отсутствуют ключи rsa и dsa, исправьте их:

ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa  -f /etc/ssh/ssh_host_dsa_key

— карбункул
источник

Это сработало для меня. Хотя я должен был быть пользователем root, чтобы запустить следующее: ssh-keygen -t dsa -f / etc / ssh / ssh_host_dsa_key

— StarDust

Ключи регенерации определенно работают. В моем случае это было изменение IP-адреса компьютера после установки openssh (и ключей, сгенерированных во время установки).

— Альфише

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

— Томас Гонсалес

8

Я переустановил биты SSH, выполнив:

sudo apt-get --reinstall install openssh-server openssh-client

Это исправило все мои проблемы.

— boehj
источник

8

Может быть совпадение. То, что проблема перестала возникать во время переустановки ssh, не является надежной гарантией причины и следствия. Кстати, с какой стороны вы переустанавливали? Или оба? В любом случае, «этот вопрос вряд ли поможет будущим посетителям».

— Каз

5

Метод änthräX очень полезен. Меня устраивает!

В основном я думаю, что после установки ssh необходимы ключевые файлы.

Единственная ревизия, которую я сделал, заключалась в использовании rsaвместо rsa1:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key 
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

Этот модифицированный метод работал для меня.

— Alan_04
источник

Это была проблема в моем случае. Пакет ssh-сервера с текущей версией Ubuntu для компьютера Utilite ARM, установленного с признаком OP. После выполнения этих двух команд (которые я сделал от имени пользователя root) я наконец могу войти в ssh. Большое спасибо. +1

— Джеймс Т Снелл

1

Это потому, что как-то /etc/sshизменились права доступа к файлам внутри ... Так что измените права доступа к файлам, как показано в примере ниже:

использовать:

chmod 644 ssh_config
chmod 600 moduli

и так далее...

Наконец, права доступа к файлу должны выглядеть примерно так, как показано ниже,

[root@hostname ssh]# ls -latr
total 172

-rw-r--r--.   1 root root   2047 Aug 12  2010 ssh_config
-rw-------.   1 root root 125811 Aug 12  2010 moduli
-rw-------.   1 root root    963 Mar  1 16:02 ssh_host_key
-rw-r--r--.   1 root root    627 Mar  1 16:02 ssh_host_key.pub
-rw-r--r--.   1 root root    382 Mar  1 16:02 ssh_host_rsa_key.pub
-rw-------.   1 root root   1675 Mar  1 16:02 ssh_host_rsa_key
-rw-r--r--.   1 root root    590 Mar  1 16:02 ssh_host_dsa_key.pub
-rw-------.   1 root root    668 Mar  1 16:02 ssh_host_dsa_key
-rw-------.   1 root root   3845 May  7 11:52 sshd_config

После изменения разрешений попробуйте подключиться из putty, должно работать нормально.

— Варун Иосиф
источник

1

Почему Putty имеет значение? И подумайте о том, чтобы спросить у ОП, какие разрешения имеются у файлов, прежде чем посоветовать ему изменить их.

— Клайв ван Хильтен

Чрезвычайно извиняюсь за неправильную публикацию ответа. Теперь вот что, во время установки некоторых приложений кто-то изменил разрешения этих файлов на 777. Это я узнал, когда проходил через / var / log / messages (последовательное подключение к машина). Следовательно, изменились разрешения, и угадайте, что? после этого все заработало нормально.

— Варун Иосиф

1

У нас была похожая проблема, но она возникала только при входе из Ubuntu в Solaris. Убедитесь, что все эти строки присутствуют /etc/ssh/ssh_config на хосте Ubuntu, исправили проблему (вы должны обнаружить, что некоторые из этих строк уже присутствуют):

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

В случае с Xubuntu мне понадобились только последние два.

— Филип Кернс
источник

0

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

Чтобы замедлить попытки, установите пакет «fail2ban»:

sudo apt-get install fail2ban

Со страницы вики fail2ban :

Fail2ban сканирует файлы журналов (например, / var / log / apache / error_log) и блокирует IP-адреса, которые показывают вредоносные признаки - слишком много сбоев пароля, поиск эксплойтов и т. Д. Обычно Fail2Ban затем используется для обновления правил брандмауэра для отклонения IP-адресов на указанное количество времени

— Liloulinx
источник

1

Пожалуйста, объясните свой ответ более подробно о том, почему это будет работать

— DnrDevil