Perché il mio timeout ssh varia in base alla posizione della rete?

15

Quando vengo trasferito in uno dei nostri server d'ufficio (che eseguono Fedora 10) da casa, la mia sessione scade dopo un periodo abbastanza breve di attività (circa 5 minuti). Ho provato a utilizzare TcpKeepAlivesul lato client, senza alcun risultato.

La cosa che non capisco è che se sono in ufficio sulla LAN aziendale, posso lasciare una sessione inattiva tutto il giorno senza che scada, quindi il comportamento sembra dipendere dalla mia posizione.

Qualche idea sul perché questo accada e su come prevenire i timeout quando non sono sulla LAN? Sto usando il client Terminal su Mac OSX se questo aiuta.

AGGIORNAMENTO - Il suggerimento di Dave Drager di usare il ServerAliveIntervalset a zero con ha TcpKeepAlive=nofunzionato per me. Per quanto riguarda alcune delle altre risposte, le ClientAliveimpostazioni ... non sono accettate dal client SSH Mac OSX.

— gareth_bowles
fonte

6

C'è un buon resoconto su questo problema qui .

Raccomandano:

ssh -o TCPKeepAlive=yes

o:

ssh -o TCPKeepAlive=no -o ServerAliveInterval=15

Tuttavia, ho un problema sul mio sito di lavoro in cui mi disconnetto dalle sessioni, dove a casa stanno bene. Credo che il mio firewall (SonicWall) potrebbe essere bloccato con TCPKeepAlive, forse a causa della NAT.

Il mio client SSH, SecureCRT, fortunatamente ha un'opzione per un protocollo "NO-OP", che credo sostanzialmente invii un comando che non fa nulla al server. Abilitando manualmente questo sono in grado di rimanere connesso. Non sono sicuro di ciò che il client del terminale MacOSX ha che è simile a quello. C'è un commento su come implementare "NO-OP" sulla riga di comando.

Infine, potresti voler utilizzare Wireshark o altri sniffer per guardare la tua connessione TCP effettiva per scoprire cosa sta succedendo. Quello sarebbe l'ultimo modo di vedere perché si stacca ancora di tanto in tanto.

— Dave Drager
fonte

Grazie, Dave - l'opzione ServerAliveInterval ha funzionato alla grande.

— gareth_bowles,

@Dave Avevo sentito che alcuni amministratori di server aggrottano le sopracciglia su questa pratica in quanto può essere (a) rischio per la sicurezza o (b) carico del server ingiustificato. Una di queste preoccupazioni è valida, IYHO?

— Jonathan Day,

Questa è un'impostazione sull'endpoint client, quindi anche se ci si trova in un ambiente ostile, ciò potrebbe aumentare la possibilità per qualcuno di falsificarti, è altamente improbabile che abbia un impatto sulla sicurezza della connessione. Non riesco davvero a vedere questo che causa un carico extra, neanche.

— Dave Drager,

@Dave: ho inserito questo comando ma ottengo quanto segue, utilizzo: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [indirizzo_indecisione:] port] [-e escape_char] [-F configfile] [- I pkcs11] [-i identity_file] [-L [indirizzo_indirizzamento:] porta: host: hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R [ bind_address:] port: host: hostport] [-S ctl_path] [-W host: port] [-w local_tun [: remote_tun]] [user @] nomehost [comando]

— user1050619

Questa correzione ha funzionato anche per PuTTY. L'unica opzione che dovevo impostare era in Connessione -> Secondi tra Keepalive: 15. La sessione SSH è stata viva e vegeta per oltre 8 ore (Comcast), mentre di solito si disconnetterebbe in <30 minuti.

— Dan Dascalescu,

2

Questo probabilmente perché quando ti connetti da casa passi attraverso un firewall che chiude la sessione TCP dopo un breve periodo di tempo. Ma TcpKeepAlive dovrebbe evitare questo. Hai abilitato TcpKeepAlive sul lato client o sul lato server?

— raggio
fonte

Ho eseguito TcpKeepAlive sul lato client (nella mia ~ / .ssh / config) - Ho pensato che questo avrebbe risolto i problemi del firewall locale, ma è ancora scaduto.

— gareth_bowles,

Di default è "on" sul lato server, ma controlla sshd_config per vedere se non è stato disabilitato.

— raggio

Alcuni firewall disconnettono una connessione TCP dopo un certo periodo ANCHE se non sono inattivi.

— TomOnTime,

Alcuni firewall disconnettono una connessione TCP dopo un certo periodo ANCHE se non sono inattivi. Il modo per rilevarlo è vedere se vieni disconnesso in modo coerente.

— TomOnTime,

Ecco le impostazioni che ho usato per correggere: TCPKeepAlive no, ClientAliveInterval 300, ClientAliveCountMax 3

— Matt Simmons,

2

Lo ricevo sempre sulla mia connessione Comcast. Il problema è che l'intervallo keep-alive del client SSH è troppo lungo per il timeout configurato nel percorso di rete. Se sei su Linux, puoi modificare i valori ServerAliveIntervale ServerAliveCounterin modo che siano inferiori ai loro valori predefiniti. Questo valore è impostato in secondi. Il file di configurazione a livello di sistema si trova (generalmente) in /etc/ssh/ssh_config. L'impostazione di questi due AND TcpKeepAlivedovrebbe aiutare a mantenere attiva la connessione.

— sysadmin1138
fonte

1

Come dice radius, alcuni firewall a stato pieno 'dimenticano' una connessione dopo un certo tempo (normalmente configurabile) e non consentiranno ulteriori comunicazioni per la connessione; si aspettano che la connessione inizi con un SYN TCP (mi riferisco alla comunicazione SSH qui).

C'è un'altra possibilità. Il percorso di rete tra casa e ufficio potrebbe presentare perdite (del tipo di pacchetto). Quando si tenta di digitare sul client SSH, se il collegamento si è bloccato per un po ', il client potrebbe rinunciare e fallire.

La configurazione keepalive sul client gestirà il primo caso qui, ma non può essere d'aiuto nel secondo caso. Il firewall di solito si trova nel perimetro del tuo ufficio e quindi potrebbe essere configurabile. Ciò contribuirebbe anche al primo punto.

Per verificare se si verificano perdite intermittenti del collegamento, è possibile mantenere attivo un "ping" in background dal computer client.

— nik
fonte

0

Puoi anche aggiungere le impostazioni suggerite da altri come valori predefiniti nel tuo ~/.ssh/configfile, quindi non devi passarle sshogni volta che avvii una connessione:

nano ~/.ssh/config e aggiungi:

TCPKeepAlive=no
ServerAliveInterval=15

— Dan Dascalescu
fonte