In tempi di lavoro forzatamente remoto di alcune cose, anche piccole, si sente maggiormente l’esigenza. E l’esigenza è sempre la molla che spinge verso il miglioramento e la ricerca delle soluzioni.

Premetto che una parte piuttosto importante del lavoro, mio e dei miei colleghi, viene svolgo via SSH sui server che gestisco.

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.

Che accada non è una novità, 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 è poco rispetto al tempo totale di lavoro. Questo, onestamente, mi aveva indotto, finora, a considerarlo un inconveniente minore a bassa priorità e in ultima analisi a trascurarlo. Per anni il problema è rimasto lì, fastidioso ma solo un pochino.

Adesso però 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.

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.

Un problema poco importante è diventato un problema molto grosso!

Così mi sono messo a messo a indagare.

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é dall’ufficio la sessione SSH resta stabile e da casa si stacca?

I due estremi della catena di comunicazione sono virtualmente identici, quindi il problema doveva essere ciò che ci sta nel mezzo: la rete tra le due macchine. In realtà anche se fondamentalmente avevo ragione, scoprirò che parte della responsabilità à anche della configurazione del server SSH.

Le parti in cui era più probabile che si annidasse il problema erano il gateway di ingresso alla rete dell’ufficio e il router di casa mia. L’inconveniente però lo hanno più o meno tutti gli utenti, quindi non può dipendere dal provider o dal router. A questo punto restava soltanto la rete dell’ufficio.

La soluzione del busillis, come la maggior parte delle volte, era lì, nel manuale di SSH, avevo semplicemente mancato di prestare la dovuta attenzione.

Vediamo se riesco a dare una spiegazione semplice di quello che ho capito:

Il server SSH, su debian è 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 è disconnesso, o semplicemente si aspetta che il client resti sempre connesso.

Quando si accede dall’esterno invece, probabilmente tutti i pacchetti inutili vengono eliminati, o forse non si aspetta più che sia sempre connesso…

Le soluzioni potrebbero essere 2: una, lato server, è quella di attivare l’opzione TCPKeepAlive con un ClientAliveInterval diverso da zero. Tuttavia, come leggo sul manuale del client SSH, TCPKeepAlive è spoofabile (rimando a questa 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ù efficace e sicura.

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ù indolore…

Di seguito ciò che si deve fare.

ssh -o "ServerAliveInterval 240" -o "ServerAliveCountMax 120" PC_remoto

Potete impostare un alias:

inserite

alias ssh_='ssh -o "ServerAliveInterval 240" -o "ServerAliveCountMax 120"'

in ~/.bash_aliases se il vostro file .bashrc contiene una riga come questa

. ~/.bash_aliases

altrimenti direttamente in .bashrc

A questo punto il comando ssh_ si connetterà in maniera stabile.

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.

Per chi ha windows con Cygwin installato, per home si intende quella di Cycwin. Non ho alcuna idea di come si faccia con Putty…

Magari queste poche righe servono a qualcuno, a me sicuramente da promemoria. 🙂