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

У меня странная проблема: когда я использую PuTTY с SSH, соединяющимся с сервером Linux, размещенным в VMware на моей локальной Windows 7 , я часто получаю сообщение об ошибке, "Network error: Software caused connection abort"и тогда окно PuTTY SSH неактивно. Обычно я могу войти на сервер с помощью PuTTY и что-то сделать, но через некоторое время (около одной или двух минут) я получаю эту ошибку. И иногда я даже не могу войти, получаю сообщение об ошибке, указывающее время ожидания.

Я думаю, что-то не так с моим VMware Player, потому что у меня есть другой рабочий стол Ubuntu, размещенный в VMware в качестве сервера хранилища кода, и чаще всего возникает ошибка тайм-аута, когда я выполняю обновление / принятие SVN. Тем не менее, я также предполагаю, что Windows 7 имеет некоторую причуду, потому что тот же сервер Ubuntu, размещенный в VMware в качестве репозитория кода, работает очень хорошо в Windows Vista! Кажется, все плохое случается после того, как я перешел с Windows XP на Windows Vista, а затем на Windows 7!

В чем может быть причина этой проблемы и как ее можно исправить?

Дополнение :

Я сделал поиск в Google и применил все методы, чтобы помочь, в том числе:

1. Включить sshd TCPKeepAlive
2. Установите SSHd ClientAliveIntervalв 900и ClientAliveCountMaxк3
3. Установите настройку соединения PuTTY «секунды между сообщениями поддержки» на 5.

Но все это не работает! И сессия SSH в PuTTY все еще прерывается через некоторое время!

Я отключил брандмауэр сервера Linux и клиентский брандмауэр Windows 7, но время входа в систему все еще истекло! Это действительно раздражает!

Иногда я могу войти, но иногда время ожидания истекло! Я действительно не знаю почему. Это сводит меня с ума!

Я должен упомянуть одну вещь: когда я использую PuTTY SSH, подключаясь к удаленному серверу, все нормально!

Когда я не смог войти в систему, ping тоже не удалось! Но как это может произойти? Я использую VMware Player для размещения сервера Linux на моей локальной машине!

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

Network Error: Software caused connection abort

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

Как сохранить активности для предотвращения отключения с Putty:

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

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

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

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

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

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

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

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

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

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

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

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

Итак, когда замазка терминала замерзает. Это выглядит так: Вы издеваетесь, презираете, нажимаете Alt + F4, чтобы закрыть шпаклевку, Mash вниз 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 пытается повторно обменяться ключами.

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

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

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

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

Подозреваемый пятнистый интернет

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

Подозреваю, проводной / беспроводной маршрутизатор

Вы подключаетесь через проводной / беспроводной маршрутизатор? Сколько этому лет? Ваш роутер может быть проблемой. Старые беспроводные и проводные технологии могут время от времени устаревать и разрывать соединения и перезапускать их, что приводит к смерти 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 (keepalive и т. Д.), Но это не помогло.

Наконец я нашел решение для моего случая. Я записал дампы 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 относится ко всему программному обеспечению и самой ОС.

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

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

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

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

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

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

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

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

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

Вкладка «Соединение»: установите значение «5» и оставьте активным

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

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

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

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

Это было отсортировано после большого количества анализа и сортировки.

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

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

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

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

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