Migliori Pratiche per Prevenire i Problemi di Timeout SSH

I timeout SSH di solito si manifestano quando il terminale si blocca dopo alcuni minuti di inattività, per poi stampare un errore di "broken pipe" o "connection reset". La causa è spesso un firewall, un gateway NAT, una VPN o un bilanciatore di carico che interrompe le sessioni TCP inattive prima che il client SSH se ne accorga.

La soluzione più utile sono i keepalive SSH dal lato client. Anche le impostazioni lato server possono aiutare, ma servono a uno scopo diverso e possono disconnettere i client inattivi se impostate in modo troppo aggressivo.

Comprendere la Causa Principale dei Timeout SSH

Un timeout SSH si verifica quando il collegamento di comunicazione tra client e server viene interrotto perché nessuna delle due parti ha rilevato attività per una durata specifica. Di solito non è il software SSH stesso, ma piuttosto i dispositivi di rete intermedi (firewall, router e tabelle NAT) che potano in modo aggressivo le connessioni inattive per conservare risorse.

Quando un firewall non vede traffico su una specifica connessione TCP per alcuni minuti, presume che la sessione sia morta e cancella lo stato della connessione. La prossima volta che il client SSH tenta di inviare dati, il server non li riceve mai, portando a un blocco della sessione e a un eventuale errore di timeout.

La soluzione è configurare SSH per inviare segnali keep-alive (piccoli pacchetti senza dati) regolarmente, assicurando che i dispositivi intermedi riconoscano la connessione come attiva.

1. Soluzioni Lato Client: Il `ServerAliveInterval`

La soluzione più comune e semplice per prevenire i timeout è configurare il client SSH per inviare periodicamente un messaggio keep-alive al server. Questo è controllato dalla direttiva ServerAliveInterval.

Come Funziona `ServerAliveInterval`

ServerAliveInterval specifica il tempo in secondi dopo il quale il client invierà un pacchetto nullo al server se non sono stati ricevuti dati dal server. Questo valore assicura che il lato client mantenga lo stato della connessione.

Configurazione Tramite `~/.ssh/config`

Questo metodo è raccomandato perché permette di impostare la configurazione a livello globale o per host, persistendo tra riavvii e diverse sessioni terminali.

Crea o modifica il tuo file di configurazione client, tipicamente situato in ~/.ssh/config:

nano ~/.ssh/config

Per applicare l'impostazione a livello globale (a tutti gli host):

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Spiegazione dei Valori:

ServerAliveInterval 60: Il client invierà un pacchetto keep-alive ogni 60 secondi se la connessione è inattiva.
ServerAliveCountMax 3: Se il client invia 3 messaggi keep-alive consecutivi senza ricevere una risposta dal server, il client terminerà la connessione. (Durata totale del timeout: 60 secondi * 3 tentativi = 180 secondi).

Configurazione Tramite Riga di Comando

Se hai bisogno di una soluzione temporanea o preferisci applicare l'impostazione solo per una singola sessione, usa l'opzione -o durante la connessione:

ssh -o "ServerAliveInterval 60" utente@host_remoto

Consiglio: Un valore da 30 a 60 secondi è di solito ideale, poiché è abbastanza frequente da bypassare la maggior parte delle regole del firewall (spesso impostate intorno ai 5 minuti) ma non così frequente da generare un overhead di rete eccessivo.

2. Soluzioni Lato Server: Imporre Keep-Alive

Mentre la soluzione lato client (ServerAliveInterval) è tipicamente sufficiente, gli amministratori che gestiscono server accessibili da molti utenti potrebbero voler imporre le impostazioni keep-alive centralmente o impostare limiti rigidi sulle connessioni inattive. Questo viene fatto nel file di configurazione del demone SSH, /etc/ssh/sshd_config.

Usare `ClientAliveInterval` e `ClientAliveCountMax`

Queste direttive sono le controparti lato server delle impostazioni del client. Indicano al server di verificare se il client è ancora connesso.

Apri il file di configurazione del demone SSH:
```
sudo nano /etc/ssh/sshd_config
```

Aggiungi o modifica le seguenti righe:

# Il server invia un messaggio client-alive dopo 300 secondi senza traffico dal client.
ClientAliveInterval 300

# Disconnette dopo 3 messaggi client-alive senza risposta.
ClientAliveCountMax 3

Nota su ClientAliveCountMax:

I messaggi ClientAliveInterval sono sonde a livello SSH, non una semplice impostazione "disconnetti dopo questo tempo di inattività". Con ClientAliveInterval 300 e ClientAliveCountMax 3, il server disconnette solo dopo circa 15 minuti di sonde senza risposta. In OpenSSH, ClientAliveCountMax 0 disabilita questi messaggi keepalive del server, quindi non è un buon esempio per imporre timeout.

Riavvia il servizio SSH per far sì che le modifiche abbiano effetto:
```
sudo systemctl reload sshd
# oppure
sudo service ssh reload
```

3. Strategie Avanzate di Resilienza

Mentre i keep-alive SSH gestiscono brevi periodi di inattività, un'interruzione di rete completa (ad esempio, cambiare rete Wi-Fi o perdere momentaneamente il segnale) interromperà comunque la connessione TCP. Per una vera resilienza, usa strumenti di gestione delle sessioni.

Utilizzare Multiplexer di Terminale (`tmux` o `screen`)

I multiplexer di terminale sono la difesa definitiva contro le interruzioni di connessione. Eseguono una sessione sul server remoto che persiste anche se la connessione del client viene interrotta. Puoi staccarti dalla sessione, riconnetterti in seguito (dallo stesso client o da uno diverso) e riattaccarti per riprendere esattamente da dove avevi lasciato.

Flusso di Lavoro Base di tmux:

Connettiti al server:
```
ssh utente@host_remoto
```
Avvia una nuova sessione tmux sul server:
```
tmux new -s mia_sessione
```
Lavora all'interno della sessione tmux.
Se la connessione cade, o devi andartene, stacca la sessione (Ctrl+B, poi D).
Riconnettiti al server tramite SSH.
Riattaccati alla tua sessione esistente:
```
tmux attach -t mia_sessione
```

Distinguere i Keep-Alive SSH dai Keep-Alive TCP

È possibile utilizzare il meccanismo TCP Keep-Alive del sistema operativo sottostante, spesso configurato tramite la direttiva TCPKeepAlive yes in sshd_config. Tuttavia, i keep-alive a livello SSH (ServerAliveInterval) sono generalmente preferiti perché:

Portabilità: Le direttive SSH funzionano in modo coerente indipendentemente dalla regolazione del kernel del sistema operativo sottostante.
Livello Applicativo: I keep-alive SSH operano all'interno del livello applicativo, assicurando che il demone SSH rimanga reattivo.
Consapevolezza del Firewall: I keep-alive TCP possono talvolta essere bloccati silenziosamente da firewall o dispositivi NAT che controllano solo l'attività del payload, mentre i keep-alive SSH sono specificamente progettati per attraversare con successo questi livelli.

Se scegli di usare TCPKeepAlive yes, ricorda che l'intervallo di temporizzazione effettivo è controllato dal sistema operativo (ad esempio, net.ipv4.tcp_keepalive_time di Linux), non dalla configurazione SSH.

Riepilogo delle Migliori Pratiche

Problema	Direttiva di Configurazione	Posizione	Valore Raccomandato	Scopo
Timeout del Client	`ServerAliveInterval`	`~/.ssh/config` (Client)	30 - 60 secondi	Invia pacchetti nulli dal client al server per prevenire l'interruzione del firewall.
Soglia di Disconnessione del Client	`ServerAliveCountMax`	`~/.ssh/config` (Client)	3 - 5	Numero di risposte mancate prima che il client si disconnetta.
Imposizione di Inattività del Server	`ClientAliveInterval`	`/etc/ssh/sshd_config` (Server)	300 secondi (5 min)	Invia controlli dal server al client per monitorare l'attività.
Resilienza della Connessione	N/D	Sessione del Server	`tmux` o `screen`	Permette la persistenza della sessione nonostante il guasto di rete.

Inizia con ServerAliveInterval nella configurazione del tuo client. Per migrazioni di lunga durata, aggiornamenti di pacchetti o indagini sui log, esegui il lavoro all'interno di tmux o screen in modo che un percorso di rete interrotto non uccida il lavoro.