Error de red PuTTY: el software provocó la cancelación de la conexión

Tengo un problema extraño: cuando uso PuTTY con SSH conectando a un servidor Linux alojado en VMware en mi Windows 7 local , a menudo recibo el error que dice "Network error: Software caused connection abort"y luego la ventana PuTTY SSH está inactiva. Por lo general, puedo iniciar sesión en el servidor con PuTTY y hacer algo, pero después de un tiempo aleatorio (aproximadamente uno o dos minutos) obtengo ese error. Y a veces ni siquiera puedo iniciar sesión, obteniendo un error que dice tiempo de espera.

Supongo que hay algo mal con mi VMware Player, porque tengo otro escritorio Ubuntu alojado en VMware como servidor de repositorio de código, y la mayoría de las veces tiene un error de tiempo de espera cuando hago una actualización / confirmación de SVN. Sin embargo, también supongo que Windows 7 tiene algunas peculiaridades porque el mismo servidor Ubuntu alojado en VMware como repositorio de código funciona muy bien cuando está en Windows Vista. ¡Parece que todas las cosas malas suceden después de que me mudé de Windows XP a Windows Vista y luego a Windows 7!

¿Cuál podría ser la razón de este problema y cómo se puede solucionar?

Suplemento :

Hice una búsqueda en Google y apliqué todos los métodos para ayudar, incluidos:

1. Habilitar sshd TCPKeepAlive
2. Establecer sshd ClientAliveIntervalen 900y ClientAliveCountMaxpara3
3. Establezca la configuración de conexión PuTTY 'segundos entre keepalives' en 5.

¡Pero todo esto no funciona! ¡Y la sesión SSH en PuTTY todavía se rompe después de algún tiempo!

Apagué tanto el servidor de seguridad del servidor Linux como el servidor de seguridad del cliente Windows 7, ¡pero el inicio de sesión aún se agota! ¡Es realmente molesto!

Parece que a veces puedo iniciar sesión, ¡pero a veces se desconecta! Realmente no sé por qué. ¡Me vuelve loco!

Una cosa que debo mencionar es que cuando uso PuTTY SSH conectando a un servidor remoto, ¡todo está bien!

Cuando no pude iniciar sesión, ¡ping falló también! Pero, ¿cómo puede suceder eso? ¡Utilizo el reproductor VMware para alojar el servidor Linux en mi máquina local!

Putty tiene una función que intenta solucionar este problema:

Network Error: Software caused connection abort

1. Comience Masilla
2. Cargue su configuración de conexión si la tiene guardada
3. Haga clic en "Conexión"
4. En la sección que dice "Envío de paquetes nulos para mantener la sesión activa", lo cambió a 5 segundos. 300 segundos pueden ser mejores si las interrupciones de la red son su problema, lea a continuación para obtener más detalles.

Cómo keepalives para evitar la desconexión con Putty:

Algunos enrutadores de red y cortafuegos deben realizar un seguimiento de todas las conexiones a través de ellos. Por lo general, estos firewalls supondrán que una conexión está inactiva si no se transfieren datos en ninguna dirección después de un cierto intervalo de tiempo. Esto puede hacer que el firewall cierre inesperadamente las sesiones PuTTY si no se ve tráfico en la sesión durante algún tiempo.

La opción keepalive ('Segundos entre keepalives') le permite configurar PuTTY para enviar datos a través de la sesión a intervalos regulares, de manera que no interrumpa la sesión de terminal real. Si encuentra que su cortafuegos está cortando las conexiones inactivas, puede intentar ingresar un valor distinto de cero en este campo. El valor se mide en segundos; así, por ejemplo, si su cortafuegos corta las conexiones después de diez minutos, es posible que desee ingresar 300 segundos (5 minutos) en el cuadro.

Reduzca el problema utilizando la masilla de autologin y la herramienta "screen"

Putty no puede manejar un wifi defectuoso que pierde conectividad por minutos a la vez. Una solución es usar el inicio de sesión automático y la pantalla.

Es un problema no trivial para la masilla volver a sincronizar su terminal después de un minuto de pérdida de conexión a Internet. Corres riesgos de ataques de hombre en el medio durante una interrupción. Tendría que volver a autenticarse de todos modos para asegurarse. La masilla no te impone eso, solo te deja caer.

Por lo tanto, use el inicio de sesión automático para que Putty pueda iniciar sesión automáticamente en su nombre.

1. Genere una clave privada con la herramienta puttygen en la computadora con la que está utilizando masilla.
2. Pegue la clave pública en su /home/youruser/.ssh/authorized_keysen el lado del servidor, en el servidor que está utilizando putty go login.
3. Haga que la clave privada sea accesible para masilla en la configuración de masilla Conexión-> SSH-> Auth
4. Agregue la clave privada especificando el archivo de clave privada en: "Archivo de clave privada para autenticación".
5. Guarde la configuración de conexión de masilla.

Entonces podría hacer doble clic en su conexión a través de masilla, y debería llevarlo directamente al terminal sin escribir nombre de usuario / contraseña.

Entonces, ahora puede conectar un inicio de sesión a masilla en esa conexión con una combinación de teclado como F6. Entonces, cuando el wifi se estropea y te caen. Aplasta F6 y vuelve a iniciar sesión.

¡PERO aún pierdes el estado de tu terminal! ¿Cómo arreglar eso? Use el programa "pantalla". Haga una nueva pantalla escribiendo 'pantalla'. Se crea una nueva pantalla.

Cuando te echan e inicias sesión automáticamente, puedes volver a conectarlo a tu pantalla. Aquí hay un tutorial sobre cómo hacerlo: http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

Es complicado escribir screeny volver a conectar cada vez que te caen. Por lo tanto, puede escribir un script que "lo llevará automáticamente a la última pantalla disponible" para que sea transparente.

Entonces, cuando la terminal de masilla se congela. Se ve así: haces un resoplido de desprecio, aprietas Alt + F4 para cerrar la masilla, aplastas F6. Y en 6 segundos estás de vuelta justo donde lo dejaste.

Aún mejor solución, en teoría

En teoría, podría escribir todo este proceso anterior, de modo que el terminal detecte cuándo se ha caído y realice todos los pasos anteriores para restablecer la conexión a Internet. Si alguien conoce un programa que hace esto, házmelo saber automáticamente. Sería genial.

Fuentes:

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

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

Solución de problemas del error de red PuTTY

Software caused connection abort

Lea lo que PuTTY tiene que decir sobre el error

Este es un error genérico producido por el código de red de Windows cuando mata una conexión establecida por alguna razón. Por ejemplo, podría suceder si retira el cable de red de la parte posterior de una computadora conectada a Ethernet, o si Windows tiene alguna otra razón similar para creer que toda la red se ha vuelto inalcanzable.

Windows también genera este error si se ha dado por vencido en la máquina en el otro extremo de la conexión respondiendo. Si la red entre su cliente y el servidor se cae y su cliente intenta enviar algunos datos, Windows hará varios intentos de enviar los datos y luego abandonará y cortará la conexión. En particular, esto puede ocurrir incluso si no escribió nada, si está utilizando SSH-2 y PuTTY intenta un intercambio de claves.

(También puede ocurrir si está utilizando keepalives en su conexión. Otras personas han informado que keepalives corrige este error para ellos. (Hay pros y contras de keepalives).)

No conocemos ninguna razón por la cual este error pueda ocurrir que represente un error en PuTTY. El problema es entre usted, su sistema Windows, su red y el sistema remoto.

Pruebe con un cliente SSH diferente

Lo más probable es que el problema exista en algún lugar entre PuTTY y el servidor SSH de destino. Para proporcionar evidencia de esto, use un cliente SSH diferente como ( http://kitty.9bis.net ) y vea si el problema también ocurre en eso. Probablemente lo hará, lo que aislará el problema de PuTTY.

Sospecha de conexión a Internet irregular

El problema puede ser la conexión a Internet irregular. Conectividad a Internet El monitoreo del tiempo de actividad de una conexión a Internet es una buena manera de determinar si su ISP está perdiendo paquetes y es el culpable de que PuTTY se caiga. Obtenga un software que pruebe el tiempo de actividad de una conexión a Internet. Por ejemplo, http://code.google.com/p/internetconnectivitymonitor/. Las desconexiones frecuentes y prolongadas de Internet constituyen un incumplimiento de los requisitos del servicio de ISP. Si este es el caso, será difícil demostrar que es culpa del ISP, ya que el soporte técnico culpa automáticamente a este tipo de problemas en su computadora, sistema operativo, enrutador y cableado a su hogar. Si está utilizando Internet por cable y está viviendo en las nubes, podría ser posible que el hardware defectuoso en las casas de sus vecinos envíe estática en la línea durante unos segundos / minutos cuando la encienden por primera vez. Finalmente, es posible que haya hardware defectuoso en la red del ISP de su hogar. El costo para los ISP para reemplazar su hardware es tan alto que muchas veces no lo harán a menos que haya suficientes suscriptores en un área para garantizar el costo.

Sospeche del enrutador alámbrico / inalámbrico

¿Se está conectando a través de un enrutador con cable / inalámbrico? ¿Qué edad tiene? Su enrutador podría ser el problema. La tecnología inalámbrica y por cable antigua puede envejecer y desconectar conexiones esporádicamente y reiniciarlas, causando que PuTTY muera. Elimine estos componentes de la ecuación y vea si eso resuelve el problema. Pruebe una conexión por cable y / o un enrutador diferente para ver si eso soluciona el problema. Tuve un enrutador inalámbrico Linksys que sufrió esta muerte lenta y soltó las conexiones y las reinició.

Sospeche del sistema operativo que proporciona la conexión SSH

La computadora a la que se está conectando con SSH tiene una política por varios segundos para mantener vivas las conexiones SSH. Este número se establece bajo por razones de seguridad, y podría aumentarlo. La ubicación de esta configuración depende del sistema operativo que esté utilizando que proporcione SSH.

Si está utilizando PuTTY a través de una máquina virtual

Si está utilizando PuTTY que pasa a través de una máquina virtual, puede haber una política en la máquina virtual que está rompiendo su conexión SSH al servidor cuando cree que está inactiva. El aumento de estos valores depende del software de la máquina virtual y del sistema operativo que esté utilizando.

Si la conexión a Internet es mala, las soluciones de conexión de cliente SSH:

Si su ISP proporciona una conexión inestable, entonces podría hacer que las desconexiones sean menos dolorosas con "ssh autologin". Lo que haces es generar una clave pública y privada. Y le dice a su servidor extranjero que deje entrar automáticamente a cualquiera que proporcione una clave privada precisa. No resuelve su problema por completo, pero cuando ocurre la interrupción del servicio de Internet, todo lo que debe hacer es cerrar la ventana, hacer doble clic en un icono e inmediatamente volverá a la línea de comando de su carpeta de inicio sin ingresar un nombre de usuario / contraseña.

Esto lo ayudará con eso: ¿Hay alguna manera de "iniciar sesión automáticamente" en PuTTY con una contraseña?

En un símbolo del sistema elevado, ejecute lo siguiente:

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

Si Receive Window Auto-Tuning Leveles normal, entonces tendrás problemas. Deshabilítelo y todo debería funcionar como solía hacerlo:

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

Trabajé con servidores CentOS de PC con Windows, y tuve el mismo problema con PuTTY. Una sesión no duró más de 1-5 minutos. Traté de jugar con la configuración PuTTY (keepalives, etc.) pero no me ayudó en absoluto.

Finalmente encontré la solución para mi caso. He grabado volcados TCP tanto en el cliente como en el servidor. Descubrí que durante 25-30 segundos antes de desconectar hay varias retransmisiones de segmentos TCP en el volcado del cliente (tanto del lado del cliente como del servidor) y finalmente PuTTY envía RST y cierra la sesión con ese error. En el volcado del servidor no vi ningún segmento del cliente en este período, incluso RST. Significa que de vez en cuando no se entregan segmentos TCP del cliente al servidor y este período es de aproximadamente 30-60 segundos. He registrado el caso varias veces y siempre hubo retransmisiones y RST final de PuTTY. Probablemente en algún lugar de la ruta los paquetes fueron descartados por equipos de red.

Para hacer una solución alternativa, aumenté el número máximo de retransmisiones de datos desde el valor predeterminado de 5 a 16. Podría evitar que PuTTY se desconecte demasiado rápido. La variable es 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpMaxDataRetransmissions'. He agregado esta variable manualmente, no se definió inicialmente en el registro de mi Windows. ¡Ayudó! Ahora veo que PuTTY se cuelga de vez en cuando, pero siempre vuelve a funcionar.

Para solucionar el problema: 1. Grabe un volcado de TCP y busque retransmisiones y RST antes de desconectarse. 2. Si encuentra los mismos segmentos de retransmisiones / RST, ajuste el número de reintentos en un servidor o cliente (depende del lado de RST).

Tenga cuidado: el cambio de la configuración de TCP se aplica a todo el software y al sistema operativo mismo.

El error Error de red: el software provocó la cancelación de la conexión de PuTTY es el resultado si hay un conflicto de dirección IP (dos o más computadoras tienen la misma dirección IP) en la red. (Tuve este problema con una Raspberry Pi que obtuvo la misma dirección IP asignada por el servidor DHCP que un dispositivo / computadora no autorizado que se configuró manualmente para usar la misma dirección IP).

En este caso particular, podría ser un conflicto de dirección IP localmente en la computadora con Windows 7 o con otro dispositivo en la red. Wireshark se puede utilizar para rastrear con éxito este tipo de error.

El error 10053 WSAECONNABORTED(El software causó la cancelación de la conexión) es un error genérico de Winsock que puede emitirse debido a una serie de razones.

La explicación oficial dice:

Este error puede ocurrir cuando el sistema de red local cancela una conexión, como cuando Winsock cierra una conexión establecida después de que falla la retransmisión de datos (el receptor nunca reconoce los datos enviados en un socket de flujo de datos).

Los motivos de este problema pueden variar desde cables de red defectuosos hasta una simple pérdida de conectividad. Es imposible ofrecer una solución única.

Tuve el mismo problema con PuTTY después de instalar un nuevo enrutador WLAN / módem 3G para conectarme a Internet. Probé todas las soluciones de mantenimiento de vida anteriores, y todas las del menú de configuración de mi enrutador, sin ningún efecto.

Luego recordé algo de los años 90 cuando tenía un módem de teléfono fijo: la MTU (unidad de transmisión máxima), básicamente el tamaño máximo de fragmentos de datos transferidos, tuvo un efecto notable en la estabilidad de la conexión.

Así que verifiqué la configuración de mi enrutador WLAN, encontré la configuración de MTU y la cambié de un valor fijo de 1424 a "Auto" (quise probar un valor más pequeño, pero "Auto" sonaba aún mejor). Después de eso, no he tenido más problemas con PuTTY: la conexión ahora es sólida como una roca. Espero que esto ayude al menos a alguien con el problema "Error de red: el software causó la cancelación de la conexión".

Pestaña de conexión: manténgase vivo configurado en "5" segundos y habilitado

Pero mas importante:

Conexión -> SSH -> Kex , minutos máximos antes de volver a escribir : "2" (el valor predeterminado es 60).

Mi PuTTY estaba perdiendo su clave después de un tiempo, causando el tiempo de espera. Dejar ese valor en "2" minutos resolvió el problema. Me mantengo conectado indefinidamente ahora.

Me encontré con el mismo problema con un script WinSCP o una consola GUI. Finalmente descubrí que está relacionado con la velocidad (velocidad de Internet: nuestro servidor está en Internet). Moví el script a una ubicación diferente en la red, a un sitio diferente, y no tanto la GUI como el Script funcionaron bien.

Se ha resuelto después de mucho análisis y clasificación.

Necesita habilitar TCPKeepAliveen Linux.

Se explica en las preguntas frecuentes de PuTTy en el sitio web, cuando está buscando este error.

Si la máquina virtual se está ejecutando en su hardware local, desactive los paquetes mantener vivos.

En realidad estaba enfrentando estos problemas muchas veces. Busqué la solución para pasar horas, pero ninguno de ellos fue eficaz. Estoy compartiendo la solución que funcionó para mí y espero que también sea útil para otros.

Tengo Windows 10 como host O / S y Redhat-7 como invitado O / S y mi VMware había puenteado la conexión. Como DBA, tengo que visitar clientes y establecer mi configuración de red según las instalaciones del cliente. Entonces, cada vez que salgo de las instalaciones del cliente y me conecto a otra red a través de una VM inalámbrica y abierta, me enfrento al mismo problema que se indica en la pregunta. Así que pensé por un momento y verifiqué mi configuración para LAN Ethernet y Wireless Ethernet y encontré una falta de coincidencia. Como mi VM usaría automáticamente el ethernet físico entre dos para puentear. Entonces, cuando restablecí la configuración de red para LAN / Ethernet inalámbrica a DHCP, funcionó a la perfección y no se canceló más la conexión. [También puede reiniciar su máquina host después de configurarla en DHCP.]