76

У меня странная проблема: когда я использую 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 на моей локальной машине!

12 ответов12

56

У 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 go login.
  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

9

Устранение ошибок сети 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 с паролем?

4

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

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
3

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

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

2

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

2

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

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

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

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

1

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

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

1

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

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

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

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

1

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

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

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

0

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

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

0

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

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

0

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .