Connessioni SSH che si bloccano dopo pochi minuti di inattività
da Davide Riboldi · pubblicato il 14 Marzo, 2013 · modificato il 26 Novembre, 2017

In questo articolo vi parlerò di un problema molto diffuso nelle connessioni SSH utilizzate per gestire i collegamenti tra le macchine linux. Come molti avranno notato con il protocollo SSH-2, le connessioni remote tramite SSH hanno cominciato a manifestare problemi di scollegamento o congelamento delle sessioni, specialmente in presenza di Firewall o NAT. Nel momento in cui ci prendiamo una pausa dal nostro computer molto spesso al nostro ritorno ci ritroviamo con la sessione bloccata o scollegata e questo risulta veramente frustrante.

Per poter ovviare a questo possiamo agire in due modi, modificando la configurazione dei file SSH sul lato server oppure sul lato client. In questo articolo vedremo tutti e due i metodi, ma se dovessimo scegliere tra uno o l’altro suggerisco di modificare la configurazione del lato client, specialmente se gestiamo svariati server linux, di cui magari non su tutti abbiamo i privilegi amministrativi per poter modificare i file di configurazione e le impostazioni di SSH. Il file da modificare è ssh_config dove dobbiamo inserire i seguenti parametri aggiuntivi:

SSH – Modifica configurazione sul lato client

sudo vi /etc/ssh/ssh_config
ServerAliveInterval 60
ServerAliveCountMax 3

Il parametro ServerAliveInterval, imposta un intervallo di tempo espresso in secondi, entro i quali se nessun dato viene ricevuto dal server il client manda attraverso il tunnel ssh un messaggio per ottenere una risposta dal server e tenere in vita la connessione attuale. Il parametro ServerAliveCountMax invece imposta il numero massimo di messaggi che vengono inviati senza che si riceva una risposta dal server.

In questo tipo di configurazione ogni 60 secondi viene inviato un messaggio alla macchina remota, il quale ci permette di mantenere continuamente viva la connessione, ma se dopo tre tentativi consecutivi non si riceve una risposta la connessione viene chiusa. Ovviamente questi parametri saranno impostati in base alle proprie esigenze.

SSH – Modifica configurazione lato server

Per quanto riguarda le modifiche lato server il file di configurazione da modificare è sshd_config e come per la modifica lato client basta inserire due nuovi parametri:

sudo vi /etc/ssh/sshd_config
ClientAliveInterval 60
ClientAliveCountMax 3

Il principio di funzionamento è lo stesso che abbiamo visto nella configurazione lato client, solo che anzichè essere il client a mandare il messaggio di keep alive è il server ad inviarlo verso il client, sempre attraverso il tunnel. Purtroppo in questo caso, una volta modificato il file di configurazione sshd_config, per rendere effettive le modifiche bisogna riavviare il server SSH.

sudo service ssh restart (comando in base alla distribuzione)

SSH – Soluzioni alternative alla gestione del timeout

Grazie a questi piccoli accorgimenti adesso possiamo prenderci una pausa in piena serenità… o forse no… ma sono veramente così sicuro che questo basti…. ed ecco che nella mia mente comincia ad insinuarsi un dubbio. Ma cosa succede se internet non funziona più, se l’energia elettrica mi abbandona, se il mio computer scoppia… e in quel preciso istante stava girando la compilazione del kernel o l’installazione di un applicativo? Non preoccupatevi, con molta probabilità tutto quello che stavate eseguendo sulla macchina remota si interromperà e il vostro lavoro verrà perso. Però non disperate c’è una soluzione anche a questo e il suo nome è Screen.

Connessione remota tramite Screen

Forse come comando non è molto conosciuto, ma una volta che comincerete ad utilizzarlo non lo lascerete più. Se sul vostro server questo comando non è presente cominciate ad installarlo. Adeguate il comado in base alla distribuzione.

sudo apt-get install screen

Screen permette di creare delle finestre indipendenti con una propria shell all’interno ogni volta che viene lanciato, e mantiene il vostro processo attivo al suo interno fino a che non viene volutamente chiusa la finestra o eseguito un kill sul processo. Vediamo di spiegare il suo funzionamento per capire meglio come questo comando lavora. Per prima cosa collegatevi in SSH sul server remoto e lanciate il comando screen.

screen

A questo punto verrete immediatamente catapultati all’interno della finestra di screen. Se vi compare una schermata con licenza GPL premete il tasto di invio.  Apparentemente vi sembrerà tutto uguale a prima, anche perché il prompt dei comandi non cambia, la grande differenza sta nel fatto che da adesso in poi tutti i comandi che lancerete verranno eseguiti all’interno di questa finestra, in maniera indipendente e autonoma dalla vostra sessione terminale.

Se eseguiamo il comando top all’interno di screen tutto apparirà come sempre e verranno visualizzati i processi di Linux. Ma se a questo punto premete la combinazione di tasti CTRL+A+D eseguirete il detach della finestra e il processo continuerà a girare in maniera autonoma come se fosse in batch e vi verrà restituito il prompt dei comandi. A questo punto digitate anche il comando specificato e una volta dato l’invio ripremete la combinazione di tasti CTRL+A+D:

screen vmstat 1 5000

A questo punto sul server vi ritroverete con due processi attivi di screen e al loro interno in tempo reale staranno girando i comandi che abbiamo appena lanciato:

ps ax | grep SCREEN
8587 ? Ss 0:00 SCREEN top
8590 ? Ss 0:00 SCREEN vmstat 1 5000

Ed è proprio in questo momento che avviene un piccolo miracolo. Se adesso chiudete la sessione di SSH i processi rimarranno attivi sul server e continueranno a girare indisturbati, la stessa cosa succederebbe anche se staccate lavorando all’interno di una sessione di Screen e improvvisamente la connessione internet sparisce o il vostro PC per un qualsiasi motivo si blocca o si spegne per mancanza di corrente.

Screen continuerà a far girare i vostri processi sul server senza la minima interruzione. Ma tutto questo è bellissimo, però adesso che sono a conoscenza che niente è andato perduto come faccio a riprendere quello che stavo facendo? Ecco la risposta a questa domanda. Per prima cosa ricollegatevi in SSH sul server remoto e poi lanciate il seguente comando:

screen -list
There are screens on:
8614.pts-2.test (03/13/13 17:19:52) (Detached)
8611.pts-2.test (03/13/13 17:19:41) (Detached)
2 Sockets in /var/run/screen/S-root.

con questo comando potrete visualizzare tutti i processi screen attualmente attivi e potrete richiamarli con l’opzione -r specificando il numero di PID del processo.

screen -r 8614

Ubuntu top

Ed ecco qua che il processo è ancora attivo e continua a girare indisturbato, a questo punto potete decidere se rifare il detach della sessione con la combinazione di tasti CTRL+A+D o se terminare il processo di screen con un CTRL+C. Se invece state lavorando in maniera interattiva in una sessione screen è sufficiente eseguire il comando exit. Spero di essere stato  esaustivo su questa problematica che affligge molti sistemisti e di aver dato uno spunto per poter risolvere la situazione. A questo punto non mi resta che augurarvi una buona connessione a tutti!

1 Commento

  1. Grazie Davide, proprio quello che cercavo, alla fine bastava una soluzione così semplice per evitare questo maledetto problema. Penso che da oggi l'utilizzo di screen farà sempre parte delle mie operazioni giornaliere su linux.

condividi