Mar 032013
 

Molti firewall NAT o server VPN fanno scadere le sessioni inattive dopo un certo periodo di tempo per mantenere le loro linee pulite. A volte l’intervallo che deve esserci tra i pacchetti di sessione è di 24 ore, ma su alcuni firewall più semplici, le connessioni vengono uccise dopo appena 300 secondi, e questo può essere un problema se si sta lavorando su una macchina remota e all’improvviso ci si ritrova disconnessi con un messaggio “Connection reset by peer”.

In un precedente articolo ho presentato autossh, una soluzione che viene in vostro aiuto quando si vuole essere sicuri che una connessione SSH rimanga sempre attiva tra 2 macchine. Autossh è un semplice programma che permette di eseguire un’istanza di ssh, tenerla sotto controllo, e riavviare l’istanza stessa una volta che la connessione viene interrotta fino a un numero massimo di volte controllate da una variabile di ambiente.

Questo è utile se avete bisogno di avere un connessione “permanente” tra le 2 macchine, ma forse avete solo bisogno di avere una connessione tra il vostro computer personale e server diversi, e, in questi casi autossh è meno utile, quindi vediamo come utilizzare alcune opzioni di openssh per mantenere la nostra connessione aperta.


Con openssh è facile inviare un pacchetto ogni n secondi in modo da mantenere la connessione “viva”, questo è controllata da 2 parametri: ServerAliveCountMax e ServerAliveInterval.

ServerAliveCountMax
Imposta il numero di messaggi ServerAlive (vedi sotto) che può essere inviato senza che ssh riceva alcun messaggio di ritorno dal server. Se questa soglia viene raggiunta mentre i messaggi ServerAlive vengono inviati, ssh si disconnette dal server, che chiude la sessione. I messaggi ServerAlive vengono inviati attraverso il canale criptato e quindi non saranno catturabili. Il meccanismo di ServerAlive è prezioso quando il client o server dipendono dal sapere quando la connessione è diventata inattiva.

Il valore predefinito è 3. Se, ad esempio, ServerAliveInterval (vedi sotto) è impostato su 15 e ServerAliveCountMax è configurato al valore predefinito, se il server non risponde, ssh si scollega dopo circa 45 secondi. Questa opzione si applica solo alla versione del protocollo 2.

ServerAliveInterval
Consente di impostare un intervallo di timeout in secondi dopo il quale se i dati non sono stati ricevuti dal server, ssh invia un messaggio attraverso il canale crittografato per richiedere una risposta dal server. Il valore predefinito è 0, indicando che questi messaggi non verranno inviati al server, o 300 se l’opzione BatchMode è impostata. Questa opzione si applica solo alla versione 2 del protocollo.

Impostarlo lato client

Per attivare le opzioni che mantengono le sessioni in vita a livello di sistema (accesso root richiesto), è necessario modificare il file /etc/ssh/ssh_config aggiungendo queste opzioni:

Host *
    ServerAliveInterval 300
    ServerAliveCountMax 3

In alternativa è anche possibile impostare le impostazioni per solo il proprio user, modificando il file (o creandolo se non esiste) ~/.ssh/config , le opzioni sono esattamente le stesse.

Impostarlo lato server

È inoltre possibile impostare il server OpenSSH affinchè mantenga tutte le connessioni con i clienti vive aggiungendo quanto segue al file /etc/ssh/sshd_config:

ServerAliveInterval 300
ServerAliveCountMax 3

Queste impostazioni faranno in modo che il client o il server SSH inviino un pacchetto nullo verso l’altro ogni 300 secondi (5 minuti), e rinuncino se non ricevono alcuna risposta dopo 3 tentativi, a questo punto è probabile che la connessione sia stata comunque scartato.


Popular Posts:

flattr this!

  5 Responses to “Come mantenere in vita le connessioni ssh su Linux”

  1. It seems that the ServerAliveInterval & ServerAliveCountMax sshd options are available on Ubuntu 12.04. I looked at the sshd_config man page first, and didn’t see anything about those options, but I tried it anyway on my home server. After restarting ssh, I was locked out – sshd failed to start.

    The man page for sshd_config on my Arch desktop shows those options, so maybe it requires a newer version of ssh. In any case, just a warning . . . although I’m sure everyone is smart enough not to change the sshd_config on a remote machine (without another way to access it).

    • Thanks,

      I’ll verify that on my Ubuntu at home (12.10).

    • DR, On the server side, you would be looking for “ClientAliveInterval”. For “ServerAliveInterval” look on the client side, that would be the man page for ssh_config.

      About getting locked out, there are several things to try. One is to have a back up copy of the known good sshd configuration and have “at” call sshd pointed at the good config file. Another is to try a test run of the configuration using sshd’s extended test mode (-T). That won’t catch everything that will lock you out, but can help.

  2. Slow Snail,

    I am glad I saw your post indicating I need ClientAliveInterval on the server and vice versa, that kept me from making that mistake.

    Luckily I also found out the init.d script in Debian does a check_config before doing a restart. So a typo or something like switching client / server options does not lock me out. :-)

  3. You said :
    Set it client side in the file /etc/ssh/ssh_config
    Host *
    ServerAliveInterval 300
    ServerAliveCountMax 3
    Set it server side in the file /etc/ssh/sshd_config:
    ServerAliveInterval 300
    ServerAliveCountMax 3

    but i think it should be
    ClientAliveInterval 300
    ClientAliveCountMax 3
    in the file /etc/ssh/sshd_config.

    We set client interval in server side config file that is /etc/ssh/sshd_config and We set server interval in client side config file that is /etc/ssh/ssh_config.

    BTW thanks for such a useful info.

 Leave a Reply

(required)

(required)


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>