Erro de rede PuTTY: o software causou a interrupção da conexão

Estou com um problema estranho: quando estou usando o PuTTY com SSH para conectar a um servidor Linux hospedado no VMware no Windows 7 local , geralmente recebo o erro dizendo que "Network error: Software caused connection abort"a janela do PuTTY SSH fica inativa. Normalmente, consigo entrar no servidor com o PuTTY e fazer alguma coisa, mas após um tempo aleatório (cerca de um ou dois minutos), recebo esse erro. E às vezes nem consigo fazer login, obtendo um erro dizendo tempo limite.

Eu acho que há algo errado com o meu VMware Player, porque eu tenho outro desktop Ubuntu hospedado no VMware como um servidor de repositório de código e, na maioria das vezes, apresenta um erro de tempo limite ao fazer uma atualização / confirmação do SVN. No entanto, também acho que o Windows 7 tem algumas peculiaridades, porque o mesmo servidor Ubuntu hospedado no VMware como um repositório de código funciona muito bem quando no Windows Vista! Parece que todas as coisas ruins acontecem depois que mudei do Windows XP para o Windows Vista e depois para o Windows 7!

Qual poderia ser o motivo desse problema e como ele pode ser corrigido?

Suplemento :

Fiz uma pesquisa no Google e apliquei todos os métodos para ajudar, incluindo:

1. Ativar sshd TCPKeepAlive
2. Defina sshd ClientAliveIntervalcomo 900e ClientAliveCountMaxpara3
3. Defina a configuração da conexão PuTTY 'segundos entre keepalives' para 5.

Mas tudo isso não funciona! E a sessão SSH no PuTTY ainda termina depois de algum tempo!

Desliguei o firewall do servidor Linux e o firewall do cliente Windows 7, mas o login ainda atinge o tempo limite! É realmente chato!

Parece que às vezes eu consigo logar, mas às vezes o tempo limite para logon! Eu realmente não sei o porquê. Me deixa louco!

Uma coisa que devo mencionar é que, quando estou usando o PuTTY SSH, conectando-me a um servidor remoto, está tudo bem!

Quando falhei, o ping também falhou! Mas como isso pode acontecer? Eu uso o VMware player para hospedar o servidor Linux na minha máquina local!

O Putty possui um recurso que tenta corrigir esse problema:

Network Error: Software caused connection abort

1. Iniciar Putty
2. Carregue suas configurações de conexão se você as tiver salvo
3. Clique em "Conexão"
4. Na seção que diz "Envio de pacotes nulos para manter a sessão ativa", foi alterada para 5 segundos. 300 segundos podem ser melhores se as falhas de rede forem o seu problema, leia abaixo para obter detalhes.

Como keepalives para impedir a desconexão com Putty:

Alguns roteadores e firewalls de rede precisam acompanhar todas as conexões através deles. Geralmente, esses firewalls assumem que uma conexão está morta se nenhum dado for transferido em qualquer direção após um determinado intervalo de tempo. Isso pode fazer com que as sessões PuTTY sejam inesperadamente fechadas pelo firewall se nenhum tráfego for visto na sessão por algum tempo.

A opção keepalive ('Segundos entre keepalives') permite configurar o PuTTY para enviar dados através da sessão em intervalos regulares, de uma maneira que não perturbe a sessão real do terminal. Se você achar que seu firewall está cortando conexões inativas, tente inserir um valor diferente de zero neste campo. O valor é medido em segundos; por exemplo, se o seu firewall interromper as conexões após dez minutos, você poderá inserir 300 segundos (5 minutos) na caixa.

Reduza o problema usando o registro automático de massa e a ferramenta "tela"

O Putty não pode lidar com um wifi de baixa qualidade que perde a conectividade por alguns minutos. Uma solução alternativa é usar o login automático e a tela.

É um problema não trivial para a massa sincronizar novamente o seu terminal após um minuto perdido na conexão à Internet. Você corre riscos de ataques do meio do homem durante uma interrupção. Você precisaria se autenticar de qualquer maneira para ter certeza. Putty não impõe isso a você, apenas deixa você cair.

Portanto, use o autologin para que o putty possa efetuar login automaticamente em seu nome.

1. Gere uma chave privada com a ferramenta puttygen no computador com o qual você está.
2. Cole a chave pública no /home/youruser/.ssh/authorized_keyslado do servidor, no servidor em que você está usando o putty go, faça o login.
3. Tornar a chave privada acessível a massa nas configurações de massa Conexão-> SSH-> Autenticação
4. Adicione a chave privada especificando o arquivo de chave privada em: "Arquivo de chave privada para autenticação".
5. Salve as configurações de conexão da massa.

Depois, você poderá clicar duas vezes na sua conexão através da massa, e isso levará você diretamente ao terminal sem digitar nome de usuário / senha.

Então agora você pode conectar um login a massa nessa conexão com uma combinação de teclado como F6. Então, quando o wifi fica ruim e você cai. Você esmaga o F6 e volta a fazer login.

MAS você ainda perde o estado do seu terminal! Como consertar isso? Use o programa "tela". Crie uma nova tela digitando 'screen'. Uma nova tela é criada.

Quando você é expulso e faz o login automático, pode reconectar-se à sua tela. Aqui está um tutorial sobre como fazer isso: http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

É um incômodo digitar screene reconectar toda vez que você é descartado. Portanto, você pode escrever um script que "traga você automaticamente de volta à última tela disponível" para torná-lo transparente.

Então, quando o terminal da massa congelar. Parece assim: você faz um desdém com desprezo, pressiona Alt + F4 para fechar a massa e esmaga F6. E em 6 segundos você está de volta exatamente de onde parou.

Solução ainda melhor, em teoria

Em teoria, você pode criar um script para todo esse processo acima, para que o terminal detecte quando ele foi descartado e execute todas as etapas acima para restaurar a conexão com a Internet. Se alguém conhece um programa que faz isso automaticamente, me avise. Seria legal.

Fontes:

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

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

Solução de problemas do erro de rede PuTTY

Software caused connection abort

Leia o que PuTTY tem a dizer sobre o erro

Este é um erro genérico produzido pelo código de rede do Windows quando ele mata uma conexão estabelecida por algum motivo. Por exemplo, isso pode acontecer se você puxar o cabo de rede da parte traseira de um computador conectado à Ethernet ou se o Windows tiver outro motivo semelhante para acreditar que toda a rede se tornou inacessível.

O Windows também gera esse erro se desistir da máquina na outra extremidade da conexão que está respondendo. Se a rede entre o cliente e o servidor cair e o cliente tentar enviar alguns dados, o Windows fará várias tentativas para enviar os dados e desistirá e eliminará a conexão. Em particular, isso pode ocorrer mesmo se você não digitar nada, se estiver usando o SSH-2 e o PuTTY tentar uma troca de chave.

(Também pode ocorrer se você estiver usando keepalives em sua conexão. Outras pessoas relataram que os keepalives corrigem esse erro para eles. (Existem prós e contras dos keepalives.))

Não temos conhecimento de nenhum motivo pelo qual esse erro possa ocorrer, o que representaria um bug no PuTTY. O problema está entre você, seu sistema Windows, sua rede e o sistema remoto.

Tente um cliente SSH diferente

Provavelmente, o problema existe em algum lugar entre o PuTTY e o servidor SSH de destino. Para fornecer evidências disso, use um cliente SSH diferente como ( http://kitty.9bis.net ) e veja se o problema também acontece. Provavelmente irá isolar o problema do PuTTY.

Suspeita de conexão com a Internet irregular

O problema pode ser a conexão irregular à Internet. Conectividade com a Internet O monitoramento do tempo de atividade de uma conexão com a Internet é uma boa maneira de determinar se o seu provedor de serviços de Internet está perdendo pacotes e é o culpado pela queda do PuTTY. Obtenha algum software que teste o tempo de atividade de uma conexão com a Internet. Por exemplo, http://code.google.com/p/internetconnectivitymonitor/. Desconexões frequentes e longas da Internet são uma violação dos requisitos de serviço do ISP. Se for esse o caso, será difícil provar que é culpa do ISP, pois o suporte técnico culpa automaticamente esses tipos de problemas no seu computador, sistema operacional, roteador e fiação em sua casa. Se você estiver usando a Internet a cabo e morando no meio do nada, é possível que o hardware defeituoso nas casas dos seus vizinhos esteja enviando estática na linha por alguns segundos / minutos quando eles a ligam pela primeira vez. Finalmente, é possível que haja um hardware defeituoso na rede do ISP em sua casa. O custo para os ISPs substituirem seu hardware é tão alto que, muitas vezes, eles não o fazem, a menos que haja assinantes suficientes em uma área para garantir o custo.

Suspeite do roteador com fio / sem fio

Você está se conectando através de um roteador com fio / sem fio? Quantos anos tem isso? Seu roteador pode ser o problema. A tecnologia sem fio e com fio antiga pode envelhecer e eliminar esporadicamente as conexões e reiniciá-las, causando a morte do PuTTY. Remova esses componentes da equação e veja se isso resolve o problema. Tente uma conexão com fio e / ou roteador diferente para verificar se isso resolve o problema. Eu tinha um roteador sem fio da Linksys sofrendo essa morte lenta e desconectando conexões e reiniciando-as.

Suspeite do sistema operacional que fornece a conexão SSH

O computador ao qual você está se conectando com SSH possui uma política por número de segundos para manter as conexões SSH ativas. Esse número é definido como baixo por razões de segurança e você pode aumentá-lo. Onde esta configuração depende do sistema operacional que você está usando que fornece SSH.

Se você estiver usando o PuTTY através de uma máquina virtual

Se você estiver usando o PuTTY passando por uma máquina virtual, pode haver uma política na máquina virtual que esteja interrompendo sua conexão SSH com o servidor quando ele achar que está inativo. O aumento desses valores depende de qual software de máquina virtual e sistema operacional você está usando.

Se a conexão à Internet estiver ruim, as soluções alternativas de conexão do cliente SSH:

Se o seu provedor de serviços de Internet fornecer uma conexão instável, você poderá tornar as desconexões menos dolorosas com o "ssh autologin". O que você faz é gerar uma chave pública e privada. E você diz ao seu servidor estrangeiro para permitir automaticamente a entrada de qualquer pessoa que forneça uma chave privada precisa. Ele não resolve o problema completamente, mas quando a interrupção da Internet acontece, tudo o que você faz é fechar a janela, clicar duas vezes em um ícone e você será imediatamente levado de volta à linha de comando da pasta pessoal sem inserir um nome de usuário / senha.

Isso o ajudará com isso: Existe uma maneira de "logon automático" no PuTTY com uma senha?

Em um prompt de comando elevado, execute o seguinte:

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

Se Receive Window Auto-Tuning Levelfor normal, você terá problemas. Desative e, em seguida, tudo deve funcionar como costumava:

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

Trabalhei com servidores CentOS a partir de PCs com Windows e tive o mesmo problema com o PuTTY. Uma sessão não durou mais que 1 a 5 minutos. Tentei brincar com as configurações do PuTTY (keepalives, etc.), mas não ajudou em nada.

Finalmente encontrei a solução para o meu caso. Gravei despejos de TCP no cliente e no servidor. Descobri que, durante 25 a 30 segundos antes de desconectar, existem várias retransmissões de segmentos TCP no despejo do cliente (do lado do cliente e do servidor) e, finalmente, o PuTTY envia o RST e fecha a sessão com esse erro. No despejo do servidor, não vi nenhum segmento do cliente nesse período, nem o RST. Isso significa que, de tempos em tempos, nenhum segmento TCP do cliente é entregue ao servidor e esse período é de 30 a 60 segundos. Eu gravei o caso várias vezes e sempre houve retransmissões e RST final do PuTTY. Provavelmente em algum lugar na rota os pacotes foram descartados pelos equipamentos de rede.

Para fazer uma solução alternativa, aumentei o número máximo de retransmissões de dados do valor padrão de 5 para 16. Isso poderia impedir que o PuTTY fosse desconectado muito rapidamente. A variável é 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpMaxDataRetransmissions'. Eu adicionei essa variável manualmente, ela não foi definida inicialmente no registro do meu Windows. Isso ajudou! Agora vejo que o PuTTY trava de vez em quando, mas sempre volta ao trabalho.

Para corrigir o problema: 1. Registre um dump TCP e procure retransmissões e RST antes de desconectar. 2. Se você encontrar os mesmos segmentos de retransmissões / RST, ajuste o número de tentativas no servidor ou no cliente (isso depende do lado do RST).

Cuidado: a alteração das configurações de TCP se aplica a todos os softwares e sistemas operacionais.

O erro Erro de rede: O software causou a interrupção da conexão do PuTTY é o resultado se houver um conflito de endereço IP (dois ou mais computadores têm o mesmo endereço IP) na rede. (Eu tive esse problema com um Raspberry Pi que obtinha o mesmo endereço IP atribuído pelo servidor DHCP a algum dispositivo / computador não autorizado que foi configurado manualmente para usar o mesmo endereço IP.)

Nesse caso específico, pode haver um conflito de endereço IP localmente no computador com Windows 7 ou com outro dispositivo na rede. O Wireshark pode ser usado para rastrear com êxito esse tipo de erro.

O erro 10053 WSAECONNABORTED(o software causou a interrupção da conexão.) É um erro genérico do Winsock que pode ser emitido devido a vários motivos.

A explicação oficial diz:

Esse erro pode ocorrer quando o sistema de rede local interrompe uma conexão, como quando o Winsock fecha uma conexão estabelecida após a retransmissão de dados falhar (o receptor nunca reconhece os dados enviados no soquete do fluxo de dados).

Os motivos para esse problema podem variar de cabos de rede com defeito a simples perda de conectividade. É impossível oferecer uma solução única.

Eu tive o mesmo problema com o PuTTY após instalar um novo roteador WLAN / modem 3G para conectar-se à Internet. Tentei todas as soluções keep-alive acima - e todas no menu de configuração do meu roteador - sem efeito.

Então me lembrei de algo do começo dos anos 90, quando eu tinha um modem de telefone fixo: o MTU (unidade máxima de transmissão), basicamente o tamanho máximo dos blocos de dados transferidos - teve um efeito notável na estabilidade da conexão.

Por isso, verifiquei a configuração do meu roteador WLAN, encontrei a configuração da MTU e a alterei de um valor fixo de 1424 para "Auto" (pretendia tentar um valor menor, mas "Auto" parecia ainda melhor). Depois disso, não tive mais problemas com o PuTTY - a conexão agora é sólida. Espero que isso ajude pelo menos alguém com o problema "Erro de rede: o software causou uma interrupção na conexão".

Guia Conexão: mantenha ativo definido em "5" segundos e ativado

Mas mais importante:

Conexão -> SSH -> Kex , Máximo de minutos antes da re-digitação : "2" (o padrão é 60).

Meu PuTTY estava perdendo a chave depois de um tempo, causando o tempo limite. A queda desse valor para "2" minutos resolveu o problema. Fico conectado indefinidamente agora.

Corri para o mesmo problema com um script WinSCP ou console da GUI. Finalmente, descobri que isso está relacionado à velocidade (velocidade da Internet - nosso servidor está na Internet). Mudei o script para outro local na rede, site diferente, e não a GUI e o Script correram bem.

Foi resolvido após muita análise e classificação.

Você precisa ativar TCPKeepAliveno Linux.

Isso é explicado nas Perguntas frequentes do PuTTy no site, quando você está procurando esse erro.

Se a Máquina Virtual estiver em execução no seu hardware local, desative os pacotes mantidos ativos.

Na verdade, eu estava enfrentando esse problema muitas vezes. Eu procurei por horas de solução, mas nenhuma delas era eficaz. Estou compartilhando a solução que funcionou para mim e espero que também seja útil para outras pessoas.

Eu tenho o Windows 10 como host O / S e Redhat-7 como convidado O / S e meu VMware tinha uma conexão de ponte. Como DBA, tenho que visitar clientes e definir minha configuração de rede de acordo com as instalações do cliente. Portanto, sempre que deixo as instalações do cliente e me conecto a outra rede via VM aberta e sem fio, enfrento o mesmo problema conforme indicado na pergunta. Então pensei um pouco e verifiquei minha configuração para LAN Ethernet e Wireless Ethernet e encontrei uma incompatibilidade. Como minha VM usaria automaticamente a Ethernet física entre duas para fazer a ponte. Então, quando redefini a configuração de rede da LAN / Ethernet sem fio para DHCP, funcionou como um encanto e sem mais interrupções na conexão. [Você também pode reiniciar sua máquina host depois de configurá-la para DHCP.]