Errore di rete PuTTY: il software ha causato l'interruzione della connessione

Ho uno strano problema: quando sto usando PuTTY con SSH che si connette a un server Linux ospitato in VMware sul mio Windows 7 locale , ricevo spesso l'errore che dice "Network error: Software caused connection abort"e quindi la finestra di PuTTY SSH è inattiva. Di solito posso accedere al server con PuTTY e fare qualcosa, ma dopo un tempo casuale (circa uno o due minuti) ottengo quell'errore. E a volte non riesco nemmeno ad accedere, ricevendo un errore dicendo timeout.

Immagino che ci sia qualcosa di sbagliato nel mio VMware Player, perché ho un altro desktop Ubuntu ospitato in VMware come server di repository di codice, e il più delle volte ha un errore di timeout quando eseguo un aggiornamento / commit SVN. Tuttavia, immagino anche che Windows 7 abbia qualche stranezza perché lo stesso server Ubuntu ospitato in VMware come repository di codice funziona molto bene su Windows Vista! Sembra che tutte le cose brutte accadano dopo che mi sono trasferito da Windows XP a Windows Vista e poi a Windows 7!

Quale potrebbe essere la ragione di questo problema e come può essere risolto?

Supplemento :

Ho fatto una ricerca su Google e ho applicato tutti i metodi per aiutare, tra cui:

1. Abilita sshd TCPKeepAlive
2. Impostare sshd ClientAliveIntervalsu 900e ClientAliveCountMaxsu3
3. Impostare l'impostazione della connessione PuTTY 'secondi tra keepalive' su 5.

Ma questi non funzionano tutti! E la sessione SSH in PuTTY si interrompe ancora dopo qualche tempo!

Ho disattivato sia il firewall del server Linux sia il firewall del client Windows 7, ma il login è ancora scaduto! È davvero fastidioso!

A volte sembra che riesco ad accedere, ma a volte il login scade! Non so davvero perché. Mi fa impazzire!

Una cosa che devo menzionare è che quando uso PuTTY SSH si connette a un server remoto, ed è tutto OK!

Quando non riesco ad accedere, anche il ping non è riuscito! Ma come può succedere? Uso il lettore VMware per ospitare il server Linux sul mio computer locale!

Putty ha una funzione che tenta di risolvere questo problema:

Network Error: Software caused connection abort

1. Inizia Putty
2. Carica le tue impostazioni di connessione se le hai salvate
3. Fai clic su "Connessione"
4. Nella sezione che dice "Invio di pacchetti null per mantenere attiva la sessione", è stato modificato in 5 secondi. 300 secondi potrebbero essere migliori se le interruzioni di rete sono il tuo problema, leggi sotto per i dettagli.

Come keepalives per prevenire la disconnessione con Putty:

Alcuni router e firewall di rete devono tenere traccia di tutte le connessioni attraverso di essi. Di solito, questi firewall presumono che una connessione sia interrotta se nessun dato viene trasferito in nessuna direzione dopo un certo intervallo di tempo. Ciò può causare la chiusura imprevista delle sessioni PuTTY da parte del firewall se non viene rilevato traffico nella sessione per un certo periodo di tempo.

L'opzione keepalive ('Seconds between keepalives') consente di configurare PuTTY per inviare dati attraverso la sessione a intervalli regolari, in modo da non interrompere la sessione terminale effettiva. Se scopri che il tuo firewall sta interrompendo le connessioni inattive, puoi provare a inserire un valore diverso da zero in questo campo. Il valore è misurato in secondi; quindi, ad esempio, se il firewall interrompe le connessioni dopo dieci minuti, potresti voler inserire 300 secondi (5 minuti) nella casella.

Ridurre il problema utilizzando lo stucco automatico e lo strumento "schermo"

Putty non è in grado di gestire un wifi scadente che perde la connettività per minuti alla volta. Un modo per aggirare è usare autologin e schermo.

È un problema non banale per putty sincronizzare nuovamente il tuo terminale dopo una lunga perdita di connessione a Internet. Corri rischi di attacchi di mezzo uomo durante un'interruzione. Dovresti comunque autenticarti nuovamente per essere sicuro. Putty non te lo impone, ti lascia solo cadere.

Quindi usa autologin in modo che Putty possa accedere automaticamente per tuo conto.

1. Genera una chiave privata con lo strumento puttygen sul computer con cui sei stucco.
2. Incolla la chiave pubblica /home/youruser/.ssh/authorized_keyssul tuo lato server, sul server a cui stai usando putty go accedi.
3. Rendi la chiave privata accessibile allo stucco nelle impostazioni dello stucco Connessione-> SSH-> Auth
4. Aggiungi la chiave privata specificando il file della chiave privata in: "File della chiave privata per l'autenticazione".
5. Salva le impostazioni di connessione dello stucco.

Quindi sarai in grado di fare doppio clic sulla tua connessione tramite putty e ti porterà direttamente al terminale senza digitare username / password.

Quindi ora puoi agganciare un login a putty su quella connessione con una combinazione di tastiera come F6. Quindi quando il wifi si guasta e vieni lasciato cadere. Schiaccia F6 e sei di nuovo connesso.

MA perdi ancora lo stato del tuo terminale! Come risolverlo? Utilizzare il programma "schermo". Crea una nuova schermata digitando "schermo". Viene creata una nuova schermata.

Quando vieni cacciato e accedi automaticamente, puoi ricollegarti allo schermo. Ecco un tutorial su come farlo: http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

È una seccatura digitare screene riconnettersi ogni volta che vieni rilasciato. Quindi puoi scrivere uno script che "ti riporterà automaticamente all'ultima schermata disponibile" per renderlo trasparente.

Quindi, quando il terminale di stucco si blocca. Sembra così: fai uno sbuffo di disprezzo, schiaccia Alt + F4 per chiudere lo stucco, schiaccia F6. E in 6 secondi sei tornato esattamente da dove eri rimasto.

Soluzione ancora migliore, in teoria

In teoria è possibile scrivere l'intero processo sopra descritto, in modo che il terminale rilevi quando è stato eliminato e faccia tutti i passaggi precedenti per il ripristino della connessione Internet. Se qualcuno conosce un programma che lo fa, fammelo sapere automaticamente. Sarebbe pulito.

fonti:

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

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

Risoluzione dei problemi relativi all'errore di rete PuTTY

Software caused connection abort

Leggi cosa ha da dire PuTTY sull'errore

Questo è un errore generico prodotto dal codice di rete di Windows quando si interrompe una connessione stabilita per qualche motivo. Ad esempio, potrebbe succedere se si estrae il cavo di rete dal retro di un computer collegato a Ethernet o se Windows ha altri motivi simili per ritenere che l'intera rete sia diventata irraggiungibile.

Windows genera anche questo errore se si è arreso sul computer all'altra estremità della connessione rispondendo ad esso. Se la rete tra il client e il server si interrompe e il client tenta quindi di inviare alcuni dati, Windows farà diversi tentativi per inviare i dati e quindi rinuncerà e interromperà la connessione. In particolare, ciò può accadere anche se non si digita nulla, se si utilizza SSH-2 e PuTTY tenta un nuovo scambio di chiavi.

(Può accadere anche se stai usando keepalives nella tua connessione. Altre persone hanno riferito che keepalives corregge questo errore per loro. (Ci sono pro e contro di keepalives.)

Non siamo a conoscenza di alcun motivo per cui potrebbe verificarsi questo errore che rappresenterebbe un bug in PuTTY. Il problema è tra te, il tuo sistema Windows, la tua rete e il sistema remoto.

Prova un altro client SSH

Molto probabilmente il problema esiste da qualche parte tra PuTTY e il server SSH di destinazione. Per fornire prove a riguardo, utilizzare un client SSH diverso come ( http://kitty.9bis.net ) e vedere se il problema si verifica anche in questo. Probabilmente lo farà che isolerà il problema da PuTTY.

Sospetta connessione Internet discutibile

Il problema potrebbe essere la scarsa connessione a Internet. Connettività Internet Il monitoraggio del tempo di attività di una connessione Internet è un buon modo per determinare se il proprio ISP sta perdendo i pacchetti ed è la causa della caduta di PuTTY. Ottieni alcuni software che testano il tempo di attività di una connessione Internet. Ad esempio, http://code.google.com/p/internetconnectivitymonitor/. Le disconnessioni frequenti e lunghe da Internet costituiscono una violazione dei requisiti del servizio ISP. In questo caso, sarà difficile dimostrare che è colpa dell'ISP, poiché il supporto tecnico incolpa automaticamente questo tipo di problemi sul tuo computer, sistema operativo, router e cablaggio a casa. Se stai usando Internet via cavo e stai vivendo nei boonies, potrebbe essere possibile che hardware difettoso nelle case dei tuoi vicini potrebbe inviare statico sulla linea per alcuni secondi / minuti quando lo accendono per la prima volta. Infine, è possibile che ci sia hardware difettoso nella rete dell'ISP a casa tua. Il costo per gli ISP di sostituire il loro hardware è così elevato, che spesso non lo faranno a meno che non ci siano abbastanza abbonati in una zona per giustificare il costo.

Sospettare il router cablato / wireless

Ti stai collegando tramite un router cablato / wireless? Quanti anni ha? Il tuo router potrebbe essere il problema. La vecchia tecnologia wireless e cablata può rendere obsolete e far cadere sporadicamente le connessioni e riavviarle, causando la morte di PuTTY. Rimuovere questi componenti dall'equazione e vedere se questo risolve il problema. Prova una connessione cablata e / o un router diverso per vedere se questo risolve il problema. Ho avuto un router wireless Linksys subire questa morte lenta e rilasciare le connessioni e riavviarle.

Sospettare che il sistema operativo fornisca la connessione SSH

Il computer a cui ti stai connettendo con SSH ha una politica per numero di secondi per mantenere attive le connessioni SSH. Questo numero è basso per motivi di sicurezza e potresti aumentarlo. Dove si trova questa impostazione dipende dal sistema operativo in uso che fornisce SSH.

Se stai usando PuTTY attraverso una macchina virtuale

Se stai utilizzando PuTTY passando attraverso una macchina virtuale, potrebbe esserci un criterio sulla macchina virtuale che interrompe la tua connessione SSH al server quando pensa che sia inattivo. L'aumento di questi valori dipende dal software della macchina virtuale e dal sistema operativo in uso.

Se la connessione Internet è errata, soluzioni alternative alla connessione client SSH:

Se il tuo ISP fornisce una connessione instabile, potresti rendere le disconnessioni meno dolorose con "ssh autologin". Quello che fai è generare una chiave pubblica e privata. E dici al tuo server straniero di far entrare automaticamente chiunque fornisca una chiave privata accurata. Non risolve completamente il tuo problema, ma quando si verifica un'interruzione di Internet, tutto ciò che fai è chiudere la finestra, fare doppio clic su un'icona e si torna immediatamente alla riga di comando della cartella principale senza immettere un nome utente / password.

Questo ti aiuterà in questo: esiste un modo per "accedere automaticamente" in PuTTY con una password?

In un prompt dei comandi con privilegi elevati, eseguire quanto segue:

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 Levelè normale, otterrai problemi. Disabilitalo e quindi tutto dovrebbe funzionare come una volta:

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

Ho lavorato con server CentOS da PC Windows e ho avuto lo stesso problema con PuTTY. Una sessione non è durata più di 1-5 minuti. Ho provato a giocare con le impostazioni di PuTTY (keepalive, ecc.) Ma non mi è stato di alcun aiuto.

Finalmente ho trovato la soluzione per il mio caso. Ho registrato dump TCP sia sul client che sul server. Ho scoperto che durante 25-30 secondi prima di disconnettersi ci sono diverse ritrasmissioni di segmenti TCP nel dump del client (sia dal lato client che dal lato server) e infine PuTTY invia RST e chiude la sessione con quell'errore. Nel dump del server non ho visto alcun segmento dal client in questo periodo, nemmeno RST. Ciò significa che di volta in volta nessun segmento TCP dal client viene consegnato al server e questo periodo è di circa 30-60 secondi. Ho registrato il caso più volte e ci sono sempre state ritrasmissioni e RST finale da PuTTY. Probabilmente da qualche parte sul percorso i pacchetti sono stati eliminati dalle apparecchiature di rete.

Per ovviare al problema, ho aumentato il numero massimo di ritrasmissioni di dati dal valore predefinito 5 a 16. Potrebbe impedire a PuTTY di disconnettersi troppo velocemente. La variabile è "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpMaxDataRetransmissions". Ho aggiunto questa variabile manualmente, inizialmente non è stata definita nel registro del mio Windows. Mi ha aiutato! Ora vedo che PuTTY si blocca di tanto in tanto, ma torna sempre al lavoro.

Per risolvere il problema: 1. Registrare un dump TCP e cercare ritrasmissioni e RST prima di disconnettersi. 2. Se trovi gli stessi segmenti di ritrasmissione / RST, regola il numero di tentativi sul lato server o client (dipende dal lato di RST).

Attenzione: la modifica delle impostazioni TCP si applica a tutto il software e al sistema operativo stesso.

L'errore Errore di rete: il software ha causato l'interruzione della connessione da PuTTY è il risultato se si verifica un conflitto di indirizzi IP (due o più computer hanno lo stesso indirizzo IP) sulla rete. (Ho avuto questo problema con un Raspberry Pi che ha ottenuto lo stesso indirizzo IP assegnato dal server DHCP come un dispositivo / computer non autorizzato impostato manualmente per utilizzare lo stesso indirizzo IP.)

In questo caso particolare potrebbe trattarsi di un conflitto di indirizzi IP localmente sul computer Windows 7 o con un altro dispositivo sulla rete. Wireshark può essere utilizzato per rintracciare con successo questo tipo di errore.

L'errore 10053 WSAECONNABORTED(il software ha causato l'interruzione della connessione) è un errore Winsock generico che può essere emesso a causa di una serie di motivi.

La spiegazione ufficiale dice:

Questo errore può verificarsi quando il sistema di rete locale interrompe una connessione, ad esempio quando Winsock chiude una connessione stabilita dopo il fallimento della ritrasmissione dei dati (il destinatario non riconosce mai i dati inviati su un socket del flusso di dati).

Le ragioni di questo problema possono variare da cavi di rete difettosi a semplice perdita di connettività. È impossibile offrire un'unica soluzione.

Ho avuto lo stesso problema con PuTTY dopo aver installato un nuovo router WLAN / modem 3G per connettermi a Internet. Ho provato tutte le soluzioni keep-alive sopra - e tutte quelle nel menu di configurazione del mio router - senza alcun risultato.

Poi mi sono ricordato di qualcosa risalente agli anni '90 quando avevo un modem per telefono fisso: l'MTU (unità di trasmissione massima), sostanzialmente la dimensione massima dei blocchi di dati trasferiti - ha avuto un notevole effetto sulla stabilità della connessione.

Quindi ho verificato la configurazione del mio router WLAN, ho trovato l'impostazione MTU e l'ho modificata da un valore fisso di 1424 a "Auto" (intendevo provare un valore più piccolo, ma "Auto" suonava ancora meglio). Dopodiché non ho più avuto problemi con PuTTY: la connessione ora è solida. Spero che questo aiuti almeno qualcuno con il problema "Errore di rete: il software ha causato l'interruzione della connessione".

Scheda Connessione: mantenere attivo impostato su "5" secondi e abilitato

Ma soprattutto:

Connessione -> SSH -> Kex , Max minuti prima di rekey : "2" (il valore predefinito è 60).

Il mio PuTTY stava perdendo la chiave dopo un po ', causando il timeout. Eliminare quel valore a "2" minuti ha risolto il problema. Rimango connesso indefinitamente ora.

Ho riscontrato lo stesso problema con uno script WinSCP o una console GUI. Alla fine ho scoperto che è legato alla velocità (velocità di Internet - il nostro server è su Internet). Ho spostato lo script in una diversa posizione nella rete, in un sito diverso e non sia la GUI che lo Script sono andati bene.

È stato risolto dopo molte analisi e ordinamento.

È necessario abilitare TCPKeepAlivesu Linux.

È spiegato nelle FAQ di PuTTy sul sito Web, quando stai cercando questo errore.

Se la macchina virtuale è in esecuzione sul tuo hardware locale, disabilitare i pacchetti keep alive.

In realtà stavo affrontando questo problema molte volte. Ho cercato ore di soluzione ma nessuno di loro è stato efficace. Condivido la soluzione che ha funzionato per me e spero che possa essere utile anche agli altri.

Ho Windows 10 come host O / S e Redhat-7 come guest O / S e il mio VMware aveva una connessione a ponte. Come DBA devo visitare i clienti e devo impostare la mia configurazione di rete secondo le premesse del cliente. Quindi, ogni volta che esco dalla sede del cliente e mi connetto a un'altra rete tramite wireless e VM aperta, ho riscontrato lo stesso problema indicato nella domanda. Quindi ho pensato per un po 'e ho verificato la mia configurazione per LAN Ethernet e Wireless Ethernet e ho trovato una discrepanza. Dato che la mia macchina virtuale userebbe automaticamente la Ethernet fisica tra due per il collegamento. Quindi, quando ho reimpostato la configurazione di rete per LAN / Wireless Ethernet su DHCP, ha funzionato come fascino e non più interruzione della connessione. [È inoltre possibile riavviare il computer host dopo averlo impostato su DHCP.]