Вопросы Теги

Проблема SSH - сбой чтения из сокета: сброс соединения с помощью одноранговой сети

У меня была такая же проблема в Lenovo ThinkCentre, но мне нужно было работать в режиме AHCI.

Чтобы исправить ошибку загрузки 1962, я вошел в настройку BIOS (нажал F1 после запуска), перешел к STARTUP и изменил режим BOOT MODE на UEFI. Теперь, каждый раз, когда я загружаюсь, он сразу же загружается в Windows 7 без ошибок.

Я считаю, что мой MBR был поврежден (или полностью потерян), но этот метод отлично справился после восстановления резервного образа жесткого диска (который, очевидно, не был на 100% завершен).

1
задан 27 October 2014 в 11:55

5 ответов

начать мониторинг файла журнала сервера tail -f /var/log/auth.log add -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
13
ответ дан 25 May 2018 в 05:12
  • 1
    Это сработало для меня. Хотя я должен был быть root, чтобы запустить следующее: ssh-keygen -t dsa -f / etc / ssh / ssh_host_dsa_key – StarDust 28 January 2014 в 06:48
  • 2
    Ключи перерождения определенно работают. В моем случае он менял IP-адрес машины после того, как установлено openssh (и ключи, сгенерированные во время установки). – Alfishe 25 April 2015 в 05:25
  • 3
    После этого я потерял возможность подключиться к моему серверу. Пришлось попросить о помощи хостинг-провайдера. Все еще ждут ответа. Centos 7 с cPanel. – Tomas Gonzalez 11 September 2017 в 18:59

Метод ä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

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

5
ответ дан 25 May 2018 в 05:12
  • 1
    Это была проблема в моем случае. Пакет ssh-сервера с текущей версией Ubuntu для машины Utilite ARM, установленной с симптомом OP. После запуска этих двух команд (которые я сделал как root), я могу, наконец, получить ssh. Большое спасибо. +1 – James T Snell 8 July 2014 в 21:30

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

use: 

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

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

1
ответ дан 25 May 2018 в 05:12
  • 1
    Почему Putty имеет значение? И подумайте, спрашивайте у OP, какие разрешения находятся в файлах, прежде чем сообщать, что он их меняет. – Clive van Hilten 20 May 2013 в 19:02
  • 2
    Чрезвычайно жаль, что вы ответили неправильно. Теперь вот что, во время какой-то установки приложения кто-то изменил разрешения этих файлов на 777. Это я узнал, когда вы проходили через / var / log / messages (последовательное подключение к машина). Значит, изменили разрешения и угадали, что? после этого он работал нормально. – Varun Joseph 21 May 2013 в 09:18

У нас была аналогичная проблема, но это произошло только при регистрации с 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 мне нужен был только последние два.

1
ответ дан 25 May 2018 в 05:12

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

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

sudo apt-get install fail2ban

Из вики-страницы fail2ban:

Fail2ban сканирует файлы журнала (например, / var / log / apache / error_log) и запрещает IP-адреса, которые показывают вредоносные знаки - слишком много пароля сбои, поиски эксплойтов и т. д. Обычно Fail2Ban используется для обновления правил брандмауэра, чтобы отклонить IP-адреса за указанное количество времени
0
ответ дан 25 May 2018 в 05:12
  • 1
    Пожалуйста, объясните свой ответ с более подробной информацией о том, почему это будет работать – DnrDevil 13 February 2016 в 19:03

Другие вопросы по тегам:

Похожие вопросы: