ssh_exchange_identification: читання: Скидання з'єднання одноранговим

Я на OS X намагаюся вторгнутись в сервер ubuntu 12.04. Мені вдалося SSH - поки різко не припинили працювати. Я читав в Інтернеті, щоб скористатися -vналагодженням цього. Результат показаний нижче. Якщо я сш в інше поле, а потім 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

Я маю доступ адміністратора на клієнтській машині, але не на сервері.

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

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

Після входу перевірте, чи справді відображається ваша IP-адреса /etc/hosts.deny(на стороні сервера). Якщо так, то fail2banабо denyhostsповинен бути справді винуватцем.

Дивіться відповіді на це запитання щодо процедури, щоб не denyhostsблокувати вашу адресу постійно. Щоб fail2banзнайти свій ip з iptables -L --line-numberi unban з ip iptables -D <chain> <chain number>, ви перевіряєте деталі щодо howtoforge .

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

На хост-сервері видаліть ssh pub.key, розміщений тут: ~/.ssh/authorized_keysдля вашого mac. Потім, tail -f /var/log/auth.logпоки ви відкриєте інший термінал і спробуйте ssh знову ssh -v me@server. Якщо вам запропонують пароль, тоді виникла проблема з ключем ssh. Якщо ви все ще бачите 'ssh_exchange_identification: read: Відновлення з’єднання за допомогою однорангової' відповіді, тоді ви повинні мати змогу визначити, у чому проблема полягає у записі журналу у файлі '/var/log/auth.log' після вашої невдалої спроби для входу.

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

Це може статися, якщо у вас є кілька машин у мережі з однаковою MAC-адресою (наприклад, якщо ви зробите копію віртуальної машини і забудете змінити MAC).

Я отримував це завдяки серверам імен свого провайдера /etc/resolv.conf. Ці сервери імен часто перевантажені, і якщо зворотний пошук DNS не sshdвдасться, це з'єднання перестане . Я вирішив проблему, використовуючи більш надійні сервери імен, наприклад 8.8.8.8.

Я зіткнувся з тією ж проблемою. Я б відкрив сеанс 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-адреси. Я змінив на іншу адресу і проблема була вирішена

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

Я міг би припустити, що коли з'єднання впало відразу після того, як клієнт надіслав номер версії, сервер якось загрожує клієнту як несумісний.

У мене була така ж проблема, але виявилося, що причина була іншою: я використовував неправильний порт.

У нових версіях sshнаведена помилка є Connection refusedабо Bad port.

У старих версіях наведена помилка ssh_exchange_identification: read: Connection reset by peer

Тож, коли ви отримуєте таку помилку, перевірте, чи порт правильний.

Я знаю, що це питання давнє, але я хотів поділитися деякими висновками, які мав. Перевірте, чи є /var/empty/sshdна сервері відповідні права власності та дозволи.

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

Оскільки у відповіді це не було зазначено прямо, інший спосіб може з’явитися ця помилка, якщо мережевий брандмауер між вами та сервером вирішив заблокувати з'єднання. Брандмауер міг вирішити, що з IP-адреси системи OS X системи "занадто багато", і почав її блокувати. Ще не було "занадто багато" з'єднань з іншої системи, і тому це було дозволено.

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

Прикладами такої жорстокої політики з випадкової вибірки постачальників є:

• CloudFlare: Як я можу використовувати обмеження швидкості для захисту від жорстоких атак?
• F5: Налаштування захисту від нападу грубої сили
• FortiNet: створення власної підпису IPS для виявлення частоти шаблону - приклад для виявлення атаки брутальної сили
• Пало Альто: Попередити жорстокі напади
• Sonicwall: Як блокувати атаки грубої сили та словника за допомогою SRA