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з тим самим результатом, за винятком великої кількості автоматичної конфігурації, що відбувається у клієнта, що закінчується тією ж помилкою.

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

Вирішення проблем 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. В -p 10222марці sshdслухати на цьому альтернативному порт, перекриваючи файл конфігурації - це так , що він не конфліктує з потенційно запущеними sshdвипадками. Тут обов'язково виберіть вільний порт.

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

Цей метод мені багато разів допомагав у пошуку проблем, будь то проблеми аутентифікації чи інші типи. Щоб отримати дійсно багатослівний вихід stdout, використовуйте $(which sshd) -Ddddp 10222(відзначте додане, ddщоб збільшити багатослівність). Для більшої перевірки на користь налагодження man sshd.

Ви також можете мати хоста, який пам’яті настільки сильно фрагментований, що він не може виділити сторінці суміжну пам’ять для розгортання процесу для розміщення сеансу SSH.

У такому випадку ви можете отримати будь-яке повідомлення:

ssh_exchange_identification: read: Connection reset by peer

або:

Connection closed by aaa.bbb.ccc.ddd

залежно від того, наскільки далеко ходить господар, перш ніж він виходить.

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

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

Це дурна невдача, але це справді може бути вашою проблемою.

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

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

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

Або ви, можливо, зробили те, що я зробив, минулої ночі та видалили / var / empty. Мабуть, цей каталог і його дозволи мають важливе значення для функціонування sshd, і він не переробляє каталог, коли перезапуск /etc/init.d/sshdне вдасться перезапустити і нічого systemd не скаже вам, чому.

Я знайшов проблему, запустивши sshd на перший план:

# /usr/sbin/sshd -Dd
  Missing privilege separation directory: /var/empty/sshd

Перебудова каталогів вирішила проблему в моєму випадку:

drwxr-xr-x. root root  /var/empty
drwx--x--x. root root  /var/empty/sshd

Примітка для програмістів Linux: Критично важливі речі у /var/empty... дійсно ???

Я отримав помилку ssh_exchange_identification: Connection closed by remote hostпри спробі підключення до SSH: я здійснив дистанційну переадресацію порту для порту SSH 22 свого локального комп'ютера, щоб я міг тимчасово отримати доступ до нього з віддаленого сервера в Інтернеті.

Насправді помилка була тільки відображається , тому що я не пам'ятаю , що я відключив службу SSH при запуску , так що я повинен був запустити службу SSH на моєму локальному комп'ютері sudo service ssh start.

Перше, що спочатку; telnet на IP-адресу хоста, щоб перевірити, чи порт 22 насправді слухає (відкритий) на цьому хості:

telnet x.x.x.x 22

(якщо ні, то ви можете підключити консольний кабель для входу)

У моєму випадку це не працювало, і я підключив консольний кабель для входу. Після входу в систему я виявив, що всі 5 ліній VTY зайняті на цьому хості (маршрутизаторі Cisco).

Я очистив старі зв’язки, які там висіли, щоб звільнити лінії VTY, це спрацювало. Я додав команду "exec-timeout 15" під рядками VTY. Потім я зняв консольний кабель.

Урок:

Не забудьте встановити на всіх своїх пристроях 5–10 хвилин часу (якщо жодна активність не виявлена).

У моєму випадку помилково встановлено проксі-сокет (який не працює). Я отримав точно такий же ssh -vvv вихід і порожній журнал sshd.

Помилка ssh_exchange_identification: Connection closed by remote hostможе статися з незрозумілих причин. Коли я використовував код Visual Studio . Така ж помилка сталася, коли я намагався витягнути з віддаленого репо за допомогою git pullкоманди.

Я просто закрив вбудований термінал і відкрив термінал Ubuntu і знову потягнув. І це було успішно

З з CentOS Linux release 7.4.1708 (Core)з OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017за з'єднання не фільтрації портів у мене були:

ssh_exchange_identification: з'єднання закрите віддаленим хостом

І виявилося, що мій Raspberry Pi вимкнувся!

Я думав, що хост, який не працює, призведе до помилки "Нема маршруту до хоста". Raspberry Pi - позаду мого маршрутизатора провайдера, тому, мабуть, саме це закривало з'єднання.

Потім я повторив експеримент (намагаючись підключитися до вимкненого Raspberry Pi) з іншого підключення до Інтернету, також не фільтруючи порти з Debian Stretch, OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017і цього разу я очікував:

Немає маршруту для розміщення