Timeout SSH Linux [chiuso]


10

Ho avuto problemi con un paio di sistemi di timeout dopo X minuti di inattività e non sono sicuro di come risolverlo.

Ho una scatola CentOS nel mio ufficio. La connessione a SSH non può toccarlo per 2 ore ed è ancora attivo quando eseguo qualcosa.

Tuttavia, connettiti allo stesso box a casa e a volte si verificherà un timeout dopo un paio di secondi a volte dopo un paio di minuti.

Penso che sia la mia connessione a Internet, tuttavia se sto attivamente utilizzando la scatola rimarrà connessa.

Tuttavia, se smetto di scrivere su Google qualcosa, verrà visualizzato un messaggio disconnesso e devo riconnettermi.

Qualcosa che posso controllare per vedere cosa sta succedendo?


4
La documentazione per il tuo client (senza nome).
user9517

Risposte:


14

La prima cosa da esaminare è l'impostazione di ServerAliveInterval. Questo dovrebbe essere impostato sulla tua workstation.

Sui client Linux o OSX è possibile creare un file di configurazione per l'utente in ~ / .ssh / config sulla workstation. Aggiungi la seguente direttiva. Nel mio caso, voglio che influisca su tutti gli host, quindi lo inserisco in Host *.

Host *
    ServerAliveInterval 60

Questo invierà un'istruzione noop ogni 60 secondi per mantenere aperta la connessione. Potresti voler modificare il valore per soddisfare le tue esigenze.

Sul lato server assicurarsi che TCPKeepAlive sia impostato su yes.

grep TCPKeepAlive /etc/ssh/sshd_config
TCPKeepAlive yes

Se sei su Windows dovrai fare riferimento alla documentazione per il tuo client.


11

Linux non esegue il timeout delle connessioni SSH inattive. È possibile lasciare una connessione SSH aperta a tempo indeterminato e finché nessuno degli endpoint è stato riavviato o ha ottenuto un nuovo indirizzo IP, la connessione funzionerà comunque quando si accede ad essa dopo un lungo periodo di inattività.

Tuttavia, se sono presenti middlebox con stato (NAT, firewall, ecc.), È probabile che si verifichino timeout delle connessioni inattive. Il risultato è che anche se la connessione è attiva ad entrambe le estremità, i due endpoint non possono più comunicare poiché la middlebox rifiuta di inoltrare i pacchetti fino a quando il client SSH non apre una nuova connessione.

Se si conosce il timeout del middlebox, è possibile aggirare il problema configurando ClientAliveIntervalin /etc/ssh/sshd_configsul server o ServerAliveIntervalin ~/.ssh/configsul client. Per un rilevamento ottimale delle connessioni interrotte, si consiglia di abilitare entrambe le impostazioni. Questo rileverà anche le connessioni interrotte quando uno dei due endpoint è stato riavviato o ha ottenuto un nuovo indirizzo IP.

Poiché si indica che il timeout a volte sembra essere basso come pochi secondi, questo potrebbe non essere sufficiente per risolvere il problema. Un timeout apparente molto basso può essere causato da un CGN sovraccarico o non configurato correttamente. È necessario ispezionare il traffico in vari punti del percorso di comunicazione per capire se un CGN è responsabile dei guasti.

Se si scopre che i guasti sono causati dall'ISP che fa qualcosa di stupido come il bilanciamento del carico delle connessioni su più CGN che non condividono lo stato della connessione, non è possibile risolvere il problema da soli semplicemente modificando la configurazione SSH.

Se vi capita di rimanere bloccati con un ISP con un CGN inaffidabile che si rifiutano di risolvere, le uniche opzioni rimaste che conosco sono l'aggiornamento di entrambe le versioni client e server alle versioni kernel con supporto MPTCP o l'uso di una soluzione tunnel progettata per tollerare spontanea modifiche nelle mappature delle porte sul NAT.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.