Erro na Rede PuTTY: Software causou o aborto da ligação

Apenas Windows XP ou sistema operativo anterior:

Eu escrevi esta resposta há 9 anos para o Windows XP, o software Putty tem 21 anos e por isso esta resposta é útil para fins históricos. O actual Zune-OS para Desktop baseado em smartphone-OS da Window quebrou o Putty ao nível da rede, em busca de irritar todos os pontos de entrada ou saída que não fazem parte da pilha de ferramentas Pay-for-play Azure Vendor.

O Putty tem uma funcionalidade que tenta resolver este problema:

Network Error: Software caused connection abort

1. Iniciar o Putty
2. Carregue as suas definições de ligação se as tiver guardadas
3. Clique em “Connection”
4. Na secção que diz “Envio de pacotes nulos para manter a sessão activa”, Alterou para 5 segundos. 300 segundos pode ser melhor se as interrupções de rede forem o seu problema, leia abaixo para mais detalhes.

Como keepalives para evitar a desconexão com Putty:

Alguns routers de rede e firewalls precisam de manter um registo de todas as conexões através deles. Normalmente, estes firewalls assumem que uma ligação está morta se não forem transferidos dados em qualquer direcção após um determinado intervalo de tempo. Isto pode fazer com que as sessões PuTTY sejam inesperadamente fechadas pela firewall se não for visto tráfego na sessão durante algum tempo.

A opção keepalive (“Segundos entre keepalives”) permite configurar o PuTTY para enviar dados através da sessão a intervalos regulares, de forma a não perturbar a sessão terminal real. Se verificar que a sua firewall está a cortar as ligações inactivas, pode tentar introduzir um valor diferente de zero neste campo. O valor é medido em segundos; assim, por exemplo, se a sua firewall corta as ligações após dez minutos, pode querer introduzir 300 segundos (5 minutos) na caixa.

Reduza o problema utilizando o putty autologin e a ferramenta “screen ”

O Putty não consegue lidar com um wifi de merda que perde a conectividade durante minutos de cada vez. Um trabalho ao redor é usar o autologin e o ecrã.

É um problema não trivial para o putty sincronizar novamente o seu terminal após um minuto de perda prolongada na ligação à Internet. Corre-se o risco de o homem no meio de um ataque durante uma paragem. Terias de te re-autenticar de qualquer forma para teres a certeza. O putty não lhe impõe isso, apenas o deixa cair.

Então use o autologin para que o putty possa fazer o login automático em seu nome.

1. Gere uma chave privada com a ferramenta puttygen no computador com que está putty.
2. Cole a chave pública no seu /home/youruser/.ssh/authorized_keys do lado do servidor, no servidor em que está a usar o putty, faça o login.
3. Torne a chave privada acessível ao putty nas definições do putty Connection->SSH->Auth
4. 4. Adicione a chave privada especificando o ficheiro da chave privada em baixo: “Private key file for authentication”.
5. Guarde as definições de ligação do putty.

Então poderá fazer duplo clique na sua ligação através do putty, e este deverá levá-lo directamente para o terminal sem escrever o nome de utilizador/palavra-chave.

Agora pode fazer o login para fazer o putty nessa ligação com uma combinação de teclado como F6. Assim, quando o wifi se estragar e você for largado. Você faz mash down F6 e volta a entrar no sistema.

MAS você ainda perde o estado do seu terminal! Como resolver isso? Use o programa “screen”. Faça um novo ecrã escrevendo “ecrã”. É criado um novo ecrã.

Quando é expulso e faz o login automático, pode voltar a ligar o seu ecrã. Aqui está um tutorial sobre como fazer isso: http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

É um incómodo digitar screen e voltar a ligar-se sempre que for largado. Para que possa escrever um script que o “leve automaticamente de volta ao último ecrã disponível” para o tornar transparente.

Então, quando o terminal de putty congela. É o que parece: Faz-se um cheirinho de desprezo, mash down Alt+F4 para fechar o putty, Mash down F6. E em 6 segundos está de volta ao ponto onde parou.

Even solução melhor, em teoria

Em teoria, você poderia script out todo este processo acima, assim o terminal detecta quando foi deixado cair, e faz todos os passos acima para você na restauração da ligação à Internet. Se alguém conhecer um programa que faça isto, avise-me automaticamente. Seria puro.

Fontes: http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter4.html#config-keepalive http://rafaelwolf.com/?p=516

Relatar o erro da rede PuTTY

Software caused connection abort

Ler o que PuTTY tem a dizer sobre o erro

Este é um erro genérico produzido pelo código de rede Windows quando mata uma ligação estabelecida por algum motivo. Por exemplo, pode acontecer se retirar o cabo de rede da parte de trás de um computador ligado à Ethernet, ou se o Windows tiver qualquer outra razão semelhante para acreditar que toda a rede se tornou inacessível.

O Windows também gera este erro se tiver desistido da máquina na outra extremidade da ligação que lhe responde. Se a rede entre o seu cliente e o servidor cair e o seu cliente tentar enviar alguns dados, o Windows fará várias tentativas para enviar os dados e depois desistirá e matará a ligação. Em particular, isto pode ocorrer mesmo que não tenha digitado nada, se estiver a usar SSH-2 e PuTTY tenta uma troca de chaves.

(Também pode ocorrer se estiver a usar keepalives na sua ligação. Outras pessoas relataram que os keepalives corrigem este erro para eles. (Há prós e contras de keepalives.)

Não temos conhecimento de qualquer razão para que este erro possa ocorrer que represente um bug no PuTTY. O problema é entre si, o seu sistema Windows, a sua rede e o sistema remoto.

Tente um cliente SSH diferente

Muito provavelmente o problema existe algures entre o PuTTY e o servidor SSH alvo. Para o provar, utilize um cliente SSH diferente como http://kitty.9bis.net ) e veja se o problema também acontece nesse caso. Provavelmente irá isolar o problema da PuTTY.

Conexão Spotty Internet Suspeita

O problema pode ser a conexão Spotty Internet. Conectividade à Internet Monitorizar o tempo de funcionamento de uma ligação à Internet é uma boa forma de determinar se o seu ISP está a perder pacotes e é o culpado pela queda do PuTTY. Adquira algum software que teste o tempo de funcionamento de uma ligação à 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 este o caso, será difícil provar que a culpa é do ISP, pois o suporte técnico culpa automaticamente este tipo de problemas no seu computador, SO, router e cablagem para a sua casa. Se estiver a utilizar a Internet por cabo e a viver em casa, pode ser possível que hardware defeituoso na casa do seu vizinho esteja a enviar estática na linha durante alguns segundos/minutos quando o ligam pela primeira vez. Finalmente, é possível que haja hardware defeituoso na rede do ISP para a sua casa. O custo para os ISPs para substituir o seu hardware é tão elevado, que muitas vezes não o fazem a não ser que existam suficientes assinantes numa área para alertar o custo.

Suspeite o router com/sem fios

Está a ligar através de um router com/sem fios? Qual é a sua idade? O seu router pode ser o problema. A velha tecnologia sem fios e com fios pode ficar velha e deixar cair as ligações esporadicamente e reiniciá-las, causando a morte do PuTTY. Retire estes componentes da equação e veja se isso resolve o problema. Tente uma ligação com fios e/ou outro router para ver se isso resolve o problema. Tive um router sem fios Linksys que sofreu esta morte lenta e que deixou cair as ligações e as reiniciou.

Suspenda o sistema operativo que fornece a ligação SSH

O computador a que se está a ligar com SSH tem uma política de número de segundos para manter vivas as ligações SSH. Este número é definido como baixo por razões de segurança, e poderá aumentá-lo. Se estiver a utilizar o PuTTY através de uma máquina virtual**

Se estiver a utilizar o PuTTY passando por uma máquina virtual, pode haver uma política na máquina virtual que está a quebrar a sua ligação SSH ao servidor quando este pensa que está inactivo. O aumento destes valores depende do software da máquina virtual e do sistema operativo que estiver a utilizar.

** Se a ligação à Internet for má, a ligação ao cliente SSH funciona:**

Se o seu ISP fornecer uma ligação instável então 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 deixar entrar automaticamente qualquer um que forneça uma chave privada precisa. Isto não resolve completamente o seu problema, mas quando a interrupção da Internet acontece, tudo o que faz é fechar a janela, clicar duas vezes num ícone, e é imediatamente levado de volta para a sua linha de comando da pasta doméstica sem introduzir um nome de utilizador/senha.

Isto irá ajudá-lo com isso Existe alguma forma de “login automático” no PuTTY com uma senha?

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

Finalmente encontrei a solução para o meu caso. Gravei TCP dumps tanto no cliente como no servidor. Descobri que durante 25-30 segundos antes de desligar existem várias retransmissões de segmentos TCP na lixeira do cliente (tanto do lado do cliente como do lado do servidor) e finalmente o PuTTY envia RST e fecha a sessão com esse erro. No dump do servidor não vi nenhum segmento do cliente neste período, mesmo RST. Isto significa que de vez em quando nenhum segmento TCP do cliente é entregue ao servidor e este período é de cerca de 30-60 segundos. Gravei o caso várias vezes e sempre houve retransmissões e RST final da PuTTY. Provavelmente algures nos pacotes de rotas foram descartados por equipamentos de rede.

Para dar uma volta, aumentei o número máximo de retransmissões de dados do valor por defeito 5 para 16. Isto poderia evitar que o PuTTY se desligasse demasiado rápido. A variável é “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxDataRetransmissions”. Adicionei esta variável manualmente, ela não estava inicialmente definida no registo do meu Windows. Ajudou sim! Agora vejo que o PuTTY fica pendurado de vez em quando, mas volta sempre ao trabalho.

Para resolver o problema: 1. Grave um TCP dump e procure por retransmissões e RST antes de desligar. 2. Se encontrar os mesmos segmentos de retransmissões/RST, ajuste o número de tentativas de retransmissão no lado do servidor ou do cliente (depende do lado do RST).

Tenha cuidado: a alteração das definições TCP aplica-se a todo o software e ao próprio SO.

Num prompt de comando elevado, corra 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 o Receive Window Auto-Tuning Level for normal, então terá problemas. Desactive-o e depois tudo deve funcionar como dantes:

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

O erro _ Erro na rede: O software provocou o aborto_ da ligação do PuTTY é o resultado se houver um _ conflito de endereços IP_ (dois ou mais computadores têm o mesmo endereço IP) na rede. (Tive este problema com um Raspberry Pi que obteve o mesmo endereço IP atribuído pelo servidor DHCP como um dispositivo/computador desonesto que foi configurado manualmente para utilizar o mesmo endereço IP)

Neste caso específico pode ser um conflito de endereço IP localmente no computador Windows 7 ou com outro dispositivo na rede. O Wireshark pode ser utilizado para localizar com sucesso este tipo de erro.

Separador de ligação: manter vivo definido em “5” segundos e activado

Mas mais importante:

Conexão -> SSH -> Kex, Máx minutos antes de voltar a ligar: “2” (por defeito é 60).

O meu PuTTY estava a perder a chave passado algum tempo, causando o timeout. Deixar esse valor para “2” minutos resolveu o problema. Agora fico ligado indefinidamente.

O erro 10053 WSAECONNABORTED (Software caused connection abort.) é um erro genérico Winsock que pode ser emitido devido a qualquer número de razões.

A explicação oficial Winsock diz:

Este erro pode ocorrer quando o sistema de rede local aborta uma ligação, tal como quando o Winsock fecha uma ligação estabelecida após a retransmissão de dados falhar (o receptor nunca reconhece os dados enviados numa tomada de transmissão de dados).

As razões para este problema podem ir desde cabos de rede defeituosos até à simples perda de conectividade. É impossível oferecer uma única solução.

Tive o mesmo problema com o PuTTY depois de instalar um novo router WLAN / modem 3G para me ligar à Internet. Tentei todas as soluções “keep-alive” acima - e todas as do menu de configuração do meu router - sem qualquer efeito.

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

Então verifiquei a configuração do meu router WLAN, encontrei a configuração da MTU e alterei-a de um valor fixo de 1424 para “Auto” (pretendia tentar um valor menor, mas “Auto” soava ainda melhor). Depois disso, não tive mais problemas com o PuTTY - a ligação é agora sólida. Espero que isto ajude pelo menos alguém com o problema “Network error: software caused connection abort”.

Na verdade, enfrentei muitas vezes estas questões. Procurei uma solução que me permitisse passar horas, mas nenhuma delas foi eficaz. Estou a partilhar a solução que funcionou comigo e espero que também seja útil para outros.

Tenho o Windows 10 como anfitrião O/S e o Redhat-7 como convidado O/S e o meu VMware tinha uma ligação em ponte. Como DBA tenho de visitar clientes e tenho de definir a minha configuração de rede de acordo com as instalações do cliente. Assim, sempre que saio das instalações do cliente e me ligo a outra rede através de uma VM sem fios e aberta, enfrento o mesmo problema que o referido na pergunta. Por isso, pensei durante algum tempo e verifiquei a minha configuração para Ethernet LAN e Ethernet sem fios e encontrei um desajuste. Como a minha VM utilizaria automaticamente a ethernet física entre duas para fazer a ponte. Por isso, quando restabeleci a configuração de rede para LAN/Wireless Ethernet para DHCP, funcionou como um encanto e a ligação deixou de ser interrompida. Também pode reiniciar a sua máquina anfitriã depois de a configurar para DHCP].

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

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

Tem de activar o TCPKeepAlive no Linux.

É explicado na FAQ do PuTTy no site, quando está a procurar por este erro.

Se a Máquina Virtual estiver a funcionar no seu hardware local, desactive os pacotes de manutenção de vida.