Проблема з 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
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

— änthräX
джерело

Це працювало для мене. Хоча мені довелося викорінити наступне: ssh-keygen -t dsa -f / etc / ssh / ssh_host_dsa_key

— StarDust

Перевиконання ключів безумовно працює. У моєму випадку це була зміна ІР-адреси машини після встановлення opensh (і ключів, створених під час встановлення).

— Альфіше

Після цього я втратив будь-який шанс підключитися до свого сервера. Довелося попросити допомоги провайдера хостингу. Ще чекаю їхньої відповіді. Centos 7 з cPanel.

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

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), я нарешті можу вступити. Дякую. +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

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

— Варун Йосиф
джерело

1

Чому Putty актуальна? І подумайте, чи запитати ОП, які дозволи є у файлах, перш ніж порадити, що він / вона їх змінить.

— Клайв ван Гільтен

Надзвичайно вибачте за те, що розмістили відповідь невірним чином. Зараз ось у чому річ, під час встановлення додатків хтось змінив дозволи цих файлів на 777. Про це я мав знати, переходячи через / var / log / повідомлення (послідовне підключення до машина). Звідси змінив дозволи, і вгадай, що? це справно працювало після цього.

— Варун Йосиф

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-адрес протягом визначеного часу

— Лілоулінкс
джерело

1

Будь ласка, поясніть свою відповідь більш детально, чому це спрацює

— DnrDevil