In tempi di lavoro forzatamente remoto di alcune cose, anche piccole, si sente maggiormente l’esigenza. E l’esigenza \u00e8 sempre la molla che spinge verso il miglioramento e la ricerca delle soluzioni.<\/p>\n
Premetto che una parte piuttosto importante del lavoro, mio e dei miei colleghi, viene svolgo via SSH sui server che gestisco.<\/p>\n
Accade che le sessioni SSH sui miei server si disconnettano in maniera sistematica dopo qualche minuto di connessione se lasciate inattive. Questo bizzarro comportamento si verifica soltanto quando ci si connette da una rete esterna a quella del mio posto di lavoro. Quando ci si connette dalla rete interna dell’ufficio le connessioni durano giorni.<\/p>\n
Che accada non \u00e8 una novit\u00e0, succede da anni, e sarebbe un problema di poca rilevanza: in condizioni normali il tempo che ciascuno degli utenti rimane connesso ai server dall’esterno in genere \u00e8 poco rispetto al tempo totale di lavoro. Questo, onestamente, mi aveva indotto, finora, a considerarlo un inconveniente minore a bassa priorit\u00e0 e in ultima analisi a trascurarlo. Per anni il problema \u00e8 rimasto l\u00ec, fastidioso ma solo un pochino.<\/p>\n
Adesso per\u00f2 che siamo tutti costretti a lavorare da casa, una parte molto rilevante del lavoro avviene attraverso connessioni ai server dall’esterno: noi restiamo a casa.<\/p>\n
Ogni volta che un terminale viene lasciato inattivo per qualche minuto, la sessione di interrompe e tocca riloggarsi e riaprire qualsiasi cosa si stesse facendo con il rischio di perdere prezioso lavoro.<\/p>\n
Un problema poco importante \u00e8 diventato un problema molto grosso!<\/p>\n
Cos\u00ec mi sono messo a messo a indagare.<\/p>\n
Il dilemma era questo: il portatile con cui mi connetto da casa ha una configurazione software identica a quella del PC con cui mi connetto in ufficio, perch\u00e9 dall’ufficio la sessione SSH resta stabile e da casa si stacca?<\/p>\n
I due estremi della catena di comunicazione sono virtualmente identici, quindi il problema doveva essere ci\u00f2 che ci sta nel mezzo: la rete tra le due macchine. In realt\u00e0 anche se fondamentalmente avevo ragione, scoprir\u00f2 che parte della responsabilit\u00e0 \u00e0 anche della configurazione del server SSH.<\/p>\n
Le parti in cui era pi\u00f9 probabile che si annidasse il problema erano il gateway di ingresso alla rete dell’ufficio e il router di casa mia. L’inconveniente per\u00f2 lo hanno pi\u00f9 o meno tutti gli utenti, quindi non pu\u00f2 dipendere dal provider o dal router. A questo punto restava soltanto la rete dell’ufficio.<\/p>\n
La soluzione del busillis, come la maggior parte delle volte, era l\u00ec, nel manuale di SSH, avevo semplicemente mancato di prestare la dovuta attenzione.<\/p>\n
Vediamo se riesco a dare una spiegazione semplice di quello che ho capito:<\/p>\n
Il server SSH, su debian \u00e8 configurato di default per non inviare nessun segnale di keepalive. Per qualche ragione, che non ho capito, sulla rete locale in qualche modo il server trova il modo di sapere che il client non si \u00e8 disconnesso, o semplicemente si aspetta che il client resti sempre connesso.<\/p>\n
Quando si accede dall’esterno invece, probabilmente tutti i pacchetti inutili vengono eliminati, o forse non si aspetta pi\u00f9 che sia sempre connesso…<\/p>\n
Le soluzioni potrebbero essere 2: una, lato server, \u00e8 quella di attivare l’opzione TCPKeepAlive con un ClientAliveInterval diverso da zero. Tuttavia, come leggo sul manuale del client SSH, TCPKeepAlive \u00e8 spoofabile (rimando a questa<\/a> pagina wikipedia per la spiegazione di cosa significhi); l’altra, lato client, consiste nel mandare dal client un segnale KeepAlive sul canale criptato, questa sembra essere la soluzione pi\u00f9 efficace e sicura.<\/p>\n Per attivare questo comportamento o si modificano i file di configurazione (i file utente o i file di sistema) di tutti i client SSH o si da l’opzione da linea di comando. Penso che questa sia la soluzione pi\u00f9 indolore…<\/p>\n Di seguito ci\u00f2 che si deve fare.<\/p>\n Potete impostare un alias:<\/p>\n inserite<\/p>\n in ~\/.bash_aliases se il vostro file .bashrc contiene una riga come questa<\/p>\n altrimenti direttamente in .bashrc<\/p>\n A questo punto il comando ssh_ si connetter\u00e0 in maniera stabile.<\/p>\n Coloro che volessero invece cambiare il file di configurazione vi rimando al manuale di ssh_config: vanno cambiate le stesse opzioni che sono indicate nella linea di comando.<\/p>\n Per chi ha windows con Cygwin installato, per home si intende quella di Cycwin. Non ho alcuna idea di come si faccia con Putty…<\/p>\n Magari queste poche righe servono a qualcuno, a me sicuramente da promemoria. \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":" In tempi di lavoro forzatamente remoto di alcune cose, anche piccole, si sente maggiormente l’esigenza. E l’esigenza \u00e8 sempre la molla che spinge verso il miglioramento e la ricerca delle soluzioni. Premetto che una parte piuttosto importante del lavoro, mio … Continue reading ssh -o \"ServerAliveInterval 240\" -o \"ServerAliveCountMax 120\" PC_remoto<\/code><\/pre>\nalias ssh_='ssh -o \"ServerAliveInterval 240\" -o \"ServerAliveCountMax 120\"'<\/code><\/pre>\n. ~\/.bash_aliases<\/code><\/pre>\n