Meilleures pratiques pour prévenir les problèmes de timeout SSH

Les timeouts SSH se manifestent généralement lorsque votre terminal se fige après quelques minutes d'inactivité, puis affiche une erreur de pipe cassé ou de connexion réinitialisée. La cause est souvent un pare-feu, une passerelle NAT, un VPN ou un équilibreur de charge qui supprime les sessions TCP inactives avant que votre client SSH ne s'en aperçoive.

La solution la plus utile est l'utilisation de keepalives SSH depuis votre client. Les paramètres côté serveur peuvent également aider, mais ils servent un objectif différent et peuvent déconnecter les clients morts si vous les configurez de manière trop agressive.

Comprendre la cause racine des timeouts SSH

Un timeout SSH se produit lorsque le lien de communication entre le client et le serveur est rompu parce qu'aucune des deux parties n'a détecté d'activité pendant une durée spécifique. Ce n'est généralement pas le logiciel SSH lui-même, mais plutôt des dispositifs réseau intermédiaires (pare-feu, routeurs et tables NAT) qui élaguent agressivement les connexions inactives pour économiser des ressources.

Lorsqu'un pare-feu n'a pas vu de trafic sur une connexion TCP spécifique pendant quelques minutes, il suppose que la session est morte et supprime l'état de la connexion. La prochaine fois que le client SSH essaie d'envoyer des données, le serveur ne les reçoit jamais, ce qui entraîne un gel de la session et une erreur de timeout éventuelle.

La solution consiste à configurer SSH pour envoyer des signaux keep-alive (petits paquets sans données) régulièrement, garantissant ainsi que les dispositifs intermédiaires reconnaissent la connexion comme active.

1. Solutions côté client : le ServerAliveInterval

La solution la plus courante et la plus simple pour prévenir les timeouts consiste à configurer le client SSH pour envoyer périodiquement un message keep-alive au serveur. Cela est contrôlé par la directive ServerAliveInterval.

Comment fonctionne ServerAliveInterval

ServerAliveInterval spécifie le temps en secondes après lequel le client enverra un paquet nul au serveur si aucune donnée n'a été reçue du serveur. Cette valeur garantit que le côté client maintient l'état de la connexion.

Configuration via ~/.ssh/config

Cette méthode est recommandée car elle vous permet de définir la configuration globalement ou par hôte, persistant entre les redémarrages et les différentes sessions de terminal.

Créez ou modifiez votre fichier de configuration client, généralement situé à ~/.ssh/config :

nano ~/.ssh/config

Pour appliquer le paramètre globalement (à tous les hôtes) :

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Explication des valeurs :

• ServerAliveInterval 60 : Le client enverra un paquet keep-alive toutes les 60 secondes si la connexion est inactive.
• ServerAliveCountMax 3 : Si le client envoie 3 messages keep-alive consécutifs sans recevoir de réponse du serveur, le client mettra fin à la connexion. (Durée totale du timeout : 60 secondes * 3 tentatives = 180 secondes).

Configuration via la ligne de commande

Si vous avez besoin d'une solution temporaire ou préférez appliquer le paramètre uniquement pour une session unique, utilisez l'option -o lors de la connexion :

ssh -o "ServerAliveInterval 60" utilisateur@hôte_distant

Astuce : Une valeur de 30 à 60 secondes est généralement idéale, car elle est suffisamment fréquente pour contourner la plupart des règles de pare-feu (souvent réglées autour de 5 minutes) mais pas assez pour générer une surcharge réseau excessive.

2. Solutions côté serveur : appliquer les keep-alives

Bien que la solution côté client (ServerAliveInterval) soit généralement suffisante, les administrateurs gérant des serveurs accessibles par de nombreux utilisateurs peuvent souhaiter appliquer les paramètres keep-alive de manière centralisée ou définir des limites strictes sur les connexions inactives. Cela se fait dans le fichier de configuration du démon SSH, /etc/ssh/sshd_config.

Utilisation de ClientAliveInterval et ClientAliveCountMax

Ces directives sont les équivalents côté serveur des paramètres client. Elles demandent au serveur de vérifier si le client est toujours connecté.

1. Ouvrez le fichier de configuration du démon SSH :

   sudo nano /etc/ssh/sshd_config
   

2. Ajoutez ou modifiez les lignes suivantes :

   # Le serveur envoie un message client-alive après 300 secondes sans trafic client.
   ClientAliveInterval 300
   
   # Déconnecter après 3 messages client-alive sans réponse.
   ClientAliveCountMax 3
   

Remarque sur ClientAliveCountMax :

Les messages ClientAliveInterval sont des sondes de niveau SSH, et non un simple paramètre "déconnecter après ce temps d'inactivité". Avec ClientAliveInterval 300 et ClientAliveCountMax 3, le serveur ne se déconnecte qu'après environ 15 minutes de sondes sans réponse. Dans OpenSSH, ClientAliveCountMax 0 désactive ces messages keepalive du serveur, ce n'est donc pas un bon exemple d'application de timeout.

1. Redémarrez le service SSH pour que les modifications prennent effet :

   sudo systemctl reload sshd
   # ou
   sudo service ssh reload
   

3. Stratégies avancées de résilience

Bien que les keep-alives SSH gèrent les courtes périodes d'inactivité, une interruption réseau complète (par exemple, changer de réseau Wi-Fi ou perdre momentanément le signal) entraînera toujours la chute de la connexion TCP. Pour une véritable résilience, utilisez des outils de gestion de session.

Utiliser des multiplexeurs de terminal (tmux ou screen)

Les multiplexeurs de terminal sont la défense ultime contre les pertes de connexion. Ils exécutent une session sur le serveur distant qui persiste même si votre connexion client est coupée. Vous pouvez vous détacher de la session, vous reconnecter plus tard (depuis le même client ou un autre) et vous rattacher pour reprendre exactement là où vous vous êtes arrêté.

Flux de travail de base avec tmux :

1. Connectez-vous au serveur :

   ssh utilisateur@hôte_distant
   

2. Démarrez une nouvelle session tmux sur le serveur :

   tmux new -s ma_session
   

3. Travaillez à l'intérieur de la session tmux.
4. Si la connexion est perdue, ou si vous devez partir, détachez la session (Ctrl+B, puis D).
5. Reconnectez-vous au serveur via SSH.
6. Rattachez-vous à votre session existante :

   tmux attach -t ma_session
   

Distinguer les keep-alives SSH des keep-alives TCP

Il est possible d'utiliser le mécanisme TCP Keep-Alive du système d'exploitation sous-jacent, souvent configuré via la directive TCPKeepAlive yes dans sshd_config. Cependant, les keep-alives de niveau SSH (ServerAliveInterval) sont généralement préférés car :

1. Portabilité : Les directives SSH fonctionnent de manière cohérente indépendamment du réglage du noyau du système d'exploitation sous-jacent.
2. Couche application : Les keep-alives SSH opèrent au sein de la couche application, garantissant que le démon SSH reste réactif.
3. Conscience du pare-feu : Les keep-alives TCP peuvent parfois être silencieusement bloqués par des pare-feu ou des dispositifs NAT qui ne vérifient que l'activité de la charge utile, tandis que les keep-alives SSH sont spécifiquement conçus pour traverser ces couches avec succès.

Si vous choisissez d'utiliser TCPKeepAlive yes, rappelez-vous que l'intervalle de temps réel est contrôlé par le système d'exploitation (par exemple, net.ipv4.tcp_keepalive_time de Linux), et non par la configuration SSH.

Résumé des meilleures pratiques

Problème	Directive de configuration	Emplacement	Valeur recommandée	Objectif
Timeouts client	ServerAliveInterval	~/.ssh/config (Client)	30 - 60 secondes	Envoie des paquets nuls du client au serveur pour éviter la suppression par le pare-feu.
Seuil de déconnexion client	ServerAliveCountMax	~/.ssh/config (Client)	3 - 5	Nombre de réponses manquées avant que le client ne se déconnecte.
Application de l'inactivité serveur	ClientAliveInterval	/etc/ssh/sshd_config (Serveur)	300 secondes (5 min)	Envoie des vérifications du serveur au client pour surveiller l'activité.
Résilience de connexion	N/A	Session serveur	tmux ou screen	Permet la persistance de la session malgré une panne réseau.

Commencez par ServerAliveInterval dans votre configuration client. Pour les migrations de longue durée, les mises à niveau de paquets ou les investigations de logs, exécutez le travail à l'intérieur de tmux ou screen afin qu'un chemin réseau perdu ne tue pas le travail.