Ошибка сети PuTTY: программное обеспечение вызвало прерывание соединения

У Putty есть функция, которая пытается решить эту проблему:

 Network Error: Software caused connection abort 

1. Запуск шпаклевки
2. Загрузите настройки подключения, если вы их сохранили
3. Нажмите «Подключение»
4. В разделе «Отправка нулевых пакетов для сохранения сеанса» изменилось на 5 секунд. 300 секунд может быть лучше, если сбои в сети – это ваша проблема, более подробная информация приведена ниже.

Как keepalives предотвращать разъединение с Putty:

Некоторые сетевые маршрутизаторы и брандмауэры должны отслеживать все соединения через них. Обычно эти брандмауэры предполагают, что соединение мертво, если никакие данные не передаются в любом направлении после определенного интервала времени. Это может привести к неожиданному закрытию сеансов PuTTY брандмауэром, если в течение некоторого времени трафика не видно.

Параметр keepalive («Секунды между keepalives») позволяет вам настроить PuTTY для отправки данных через сеанс с регулярными интервалами таким образом, чтобы не нарушать фактический сеанс терминала. Если вы обнаружите, что ваш брандмауэр отключает простоя подключений, вы можете попробовать ввести ненулевое значение в этом поле. Значение измеряется в секундах; Так, например, если ваш брандмауэр отключит подключения через десять минут, вы можете ввести 300 секунд (5 минут) в поле.

Уменьшите проблему, используя автозаполнение putty и инструмент «screen»

Putty не может обрабатывать дрянной Wi-Fi, который теряет связь в течение нескольких минут за раз. Работа вокруг – использование автолога и экрана.

Это простая задача для штепселя повторить синхронизацию вашего терминала после минутной потери в интернет-соединении. Вы рискуете человеком в средних атаках во время перерыва. В любом случае вам придется повторно аутентифицировать себя, чтобы убедиться. Шпатлевка не навязывает это вам, это просто бросает вас.

Поэтому используйте autologin, чтобы шпатлевка могла автоматически вводиться от вашего имени.

1. Создайте закрытый ключ с помощью инструмента puttygen на компьютере, на котором вы замаскированы .
2. Вставьте открытый ключ в свои /home/youruser/.ssh/authorized_keys на стороне сервера, на сервере, на который вы используете putty go login.
3. Сделать секретный ключ доступным для замазки в настройках шпатлевки Connection-> SSH-> Auth
4. Добавьте закрытый ключ, указав файл закрытого ключа в разделе «Файл приватного ключа для аутентификации».
5. Сохраните настройки соединения шпатлевки.

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

Итак, теперь вы можете подключить логин для замазки к этому соединению с помощью комбинации клавиш, такой как F6 . Поэтому, когда Wi-Fi становится плохим, и вас отбрасывают. Вы месите F6, и вы снова вошли в систему.

НО вы все еще теряете состояние своего терминала! Как это исправить? Используйте программу «screen». Создайте новый экран, набрав «экран». Создается новый экран.

Когда вас вытаскивают и автоматически регистрируют, вы можете снова подключиться к экрану. Вот учебник о том, как это сделать: http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

Это хлопот, чтобы вводить screen и повторно подключаться каждый раз, когда вы получаете. Таким образом, вы можете написать сценарий, который «автоматически вернет вас к последнему доступному экрану», чтобы сделать его прозрачным.

Поэтому, когда терминал шпатлевки замерзает. Это выглядит так: вы делаете фырканье презрения, затирайте Alt + F4, чтобы закрыть замазку, смять F6. И через 6 секунд вы вернулись туда, где вы остановились.

Еще лучшее решение, теоретически

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

Источники:

http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter4.html#config-keepalive

http://rafaelwolf.com/?p=516

Устранение ошибки сети PuTTY

 Software caused connection abort 

Читайте, что PuTTY может сказать об ошибке

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

Windows также генерирует эту ошибку, если она отказалась от машины на другом конце подключенного к ней соединения. Если сеть между вашим клиентом и сервером опускается, и тогда ваш клиент пытается отправить некоторые данные, Windows предпримет несколько попыток отправки данных, а затем прекратит и убьет соединение. В частности, это может произойти, даже если вы ничего не написали, если вы используете SSH-2 и PuTTY предпринимает попытки повторного обмена ключами.

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

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

Попробуйте другой клиент SSH

Скорее всего, проблема существует где-то между PuTTY и целевым SSH-сервером. Чтобы предоставить доказательства для этого, используйте другой клиент SSH, например ( http://kitty.9bis.net ), и посмотрите, не возникает ли проблема в этом. Вероятно, это будет изолировать проблему от PuTTY.

Подозрительное интернет-соединение

Проблема может быть пятнистым подключением к Интернету. Подключение к Интернету. Мониторинг времени работы интернет-соединения – это хороший способ определить, потеряет ли ваш интернет-провайдер пакеты и виноват ли Путти в снижении. Получите некоторое программное обеспечение, которое проверяет время работы интернет-соединения. Например, http://code.google.com/p/internetconnectivitymonitor/ . Частые и длительные отключения от Интернета являются нарушением требований к сервису ISP. Если это так, будет сложно доказать, что это ошибка интернет-провайдера, так как техническая поддержка автоматически винит такие проблемы на вашем компьютере, ОС, маршрутизаторе и проводке до вашего дома. Если вы используете кабельный интернет и живете в бунгах, возможно, что дефектные аппаратные средства в домах вашего соседа могут отправлять статические данные на линии в течение нескольких секунд / минут, когда они сначала включаются. Наконец, возможно, что в сети ISP есть дефектное оборудование в вашем доме. Стоимость для интернет-провайдеров для замены их оборудования настолько высока, что часто они не будут этого делать, если в зоне нет достаточного количества подписчиков, чтобы избежать затрат.

Подозрительный проводной / беспроводной маршрутизатор

Вы подключаетесь через проводной / беспроводной маршрутизатор? Сколько этому лет? Возможно, ваш маршрутизатор является проблемой. Старые беспроводные и проводные технологии могут устаревать и периодически отбрасывать соединения и перезапускать их, в результате чего PuTTY умирает. Удалите эти компоненты из уравнения и убедитесь, что это решает проблему. Попробуйте подключить проводное соединение и / или другой маршрутизатор, чтобы узнать, устраняет ли это проблему. У меня был беспроводной маршрутизатор Linksys, который переносил эти медленные сообщения о смерти и удалении и перезапускал их.

Подозреваю, что операционная система, обеспечивающая соединение SSH

На компьютере, с которым вы подключаетесь с SSH, есть политика в отношении количества секунд, чтобы поддерживать соединения SSH. Этот номер установлен по соображениям безопасности, и вы можете его увеличить. Где этот параметр зависит от того, какую операционную систему вы используете, предоставляя SSH.

Если вы используете PuTTY через виртуальную машину

Если вы используете PuTTY, проходящую через виртуальную машину, на виртуальной машине может быть политика, которая нарушает ваше соединение SSH с сервером, если он считает, что он неактивен. Увеличение этих значений зависит от того, какое программное обеспечение виртуальной машины и используемая вами операционная система.

Если подключение к Интернету плохое, обходные пути подключения к SSH:

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

Это поможет вам в этом: есть ли способ «автоматического входа в систему» ​​в PuTTY с паролем?

В командной строке с повышенными правами выполните следующие действия:

 C:\Windows\system32>netsh int tcp show global Querying active state... TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State : enabled Chimney Offload State : automatic NetDMA State : enabled Direct Cache Acess (DCA) : disabled Receive Window Auto-Tuning Level : normal Add-On Congestion Control Provider : none ECN Capability : disabled RFC 1323 Timestamps : disabled 

Если уровень Receive Window Auto-Tuning Level является нормальным, вы получите проблемы. Отключите его, а затем все должно работать так, как оно используется:

 C:\Windows\system32>netsh int tcp set global autotuninglevel=disabled 

Я работал с CentOS- серверами с ПК с Windows, и у меня была такая же проблема с PuTTY. Сессия длилась не более 1-5 минут. Я пытался играть с настройками PuTTY (keepalives и т. Д.), Но это совсем не помогло.

Наконец, я нашел решение для своего дела. Я записал TCP-дампы как на клиенте, так и на сервере. Я обнаружил, что за 25-30 секунд до отключения есть несколько повторных передач сегментов TCP на дампе клиента (как со стороны клиента, так и со стороны сервера), и, наконец, PuTTY отправляет RST и закрывает сеанс с этой ошибкой. На дампе сервера я не видел никаких сегментов от клиента за этот период, даже RST. Это означает, что время от времени на сервер не доставляются сегменты TCP от клиента, и этот период составляет около 30-60 секунд. Я записал это дело несколько раз, и всегда были повторные передачи и окончательный RST из PuTTY. Вероятно, где-то на маршруте пакеты были сброшены сетевым оборудованием.

Чтобы сделать обходной путь, я увеличил максимальное количество повторных передач данных со значения по умолчанию от 5 до 16. Это может помешать PuTTY отключиться слишком быстро. Переменная: «HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpMaxDataRetransmissions». Я добавил эту переменную вручную, она не была изначально определена в моей Windows. Это помогло! Теперь я вижу, что PuTTY время от времени зависает, но он всегда возвращается к работе.

Чтобы устранить проблему: 1. Запишите дамп TCP и найдите повторные передачи и RST перед отключением. 2. Если вы найдете одни и те же сегменты повторной передачи / RST, отрегулируйте количество попыток на сервере или стороне клиента (это зависит от стороны RST).

Будьте осторожны: изменение настроек TCP применяется ко всему программному обеспечению и самой ОС.

Ошибка 10053 WSAECONNABORTED (программное обеспечение вызвало прерывание соединения.) Является общей ошибкой Winsock, которая может быть испущена по ряду причин.

Официальное объяснение гласит:

Эта ошибка может возникнуть, если локальная сетевая система прерывает соединение, например, когда Winsock закрывает установленное соединение после сбоя повторной передачи данных (приемник никогда не подтверждает данные, отправленные в гнездо потока данных).

Причины этой проблемы могут варьироваться от дефектных сетевых кабелей до простой потери связи. Невозможно предложить единое решение.

Вкладка «Соединение»: сохранить вживую в «5» секунд и включить

Но что еще более важно:

Соединение -> SSH -> Kex , Макс. Минут до ключа : «2» (по умолчанию 60).

Моя PuTTY теряла свой ключ через некоторое время, вызывая тайм-аут. Снижение этого значения до «2» минут решило проблему. Теперь я остаюсь на связи бесконечно.

Я столкнулся с такой же проблемой либо с помощью скрипта WinSCP, либо с консоли GUI. Наконец, я обнаружил, что это связано со скоростью (скорость интернета – наш сервер находится в Интернете). Я переместил сценарий в другое место в сети, на другом сайте, а не как графический интерфейс, так и скрипт.

Он был отсортирован после много анализа и сортировки.

Ошибка Ошибка сети: программное обеспечение вызвало прерывание соединения с PuTTY, это результат, если в сети существует конфликт IP-адресов (два или более компьютеров имеют одинаковый IP-адрес). (У меня была эта проблема с малиной Pi, которая получила тот же IP-адрес, назначенный сервером DHCP, как некоторое устройство / компьютер-мошенник, который был настроен вручную для использования того же IP-адреса.)

В этом конкретном случае это может быть конфликт IP-адресов локально на компьютере под управлением Windows 7 или с другим устройством в сети. Wireshark можно использовать для успешного отслеживания такого рода ошибок.

Вам нужно включить TCPKeepAlive в Linux.

Это объясняется в FAQ PuTTy на веб-сайте, когда вы ищете эту ошибку.

Если виртуальная машина работает на вашем локальном аппаратном обеспечении, отключите сохраненные пакеты.

У меня возникла такая же проблема с PuTTY после установки нового модема WLAN / 3G-модема для подключения к Интернету. Я попробовал все решения keep-alive выше – и все те, что находятся в меню конфигурации моего маршрутизатора, не имеют никакого эффекта.

Затем я вспомнил что-то со времен 90-х, когда у меня был модем на наземной линии: MTU (максимальная единица передачи), в основном максимальный размер переданных блоков данных – это оказало заметное влияние на стабильность соединения.

Поэтому я проверил конфигурацию своего маршрутизатора WLAN, нашел настройку MTU и изменил ее с фиксированного значения 1424 на «Авто» (я хотел попробовать меньшее значение, но «Авто» звучало еще лучше). После этого у меня не было больше проблем с PuTTY – теперь соединение стало твердым. Надеюсь, это поможет хотя бы кому-то с проблемой «Ошибка сетевой ошибки: программное обеспечение, вызванное отключением соединения».

Я действительно сталкивался с этими проблемами много раз. Я искал часы работы решения, но ни один из них не был эффективным. Я разделяю решение, которое сработало для меня, и я надеюсь, что это также будет полезно для других.

У меня Windows 10 в качестве хоста O / S и Redhat-7 в качестве гостевого O / S, и моя VMware соединила соединение. Как DBA я должен посетить клиентов, и я должен настроить свою конфигурацию сети в соответствии с условиями клиента. Поэтому, когда я покидаю клиентские помещения и подключаюсь к другой сети через беспроводную и открытую виртуальную машину, я столкнулся с той же проблемой, что и в вопросе. Поэтому я некоторое время думал и проверял мою конфигурацию для LAN Ethernet и Wireless Ethernet, и я нашел несоответствие. Поскольку моя виртуальная машина автоматически будет использовать физический ethernet среди двух для моста. Поэтому, когда я перезагружаю сетевую конфигурацию для LAN / Wireless Ethernet на DHCP, она работает как прелесть и больше не прерывается соединение. Вы также можете перезагрузить хост-компьютер после установки DHCP.]