Bonnes pratiques pour prévenir les problèmes de délai d'expiration SSH

Mettez fin aux déconnexions frustrantes des sessions SSH en implémentant des configurations de maintien de connexion (keep-alive) robustes. Ce guide essentiel détaille la différence entre les configurations côté client (`ServerAliveInterval`) et côté serveur (`ClientAliveInterval`), et fournit des instructions étape par étape pour ajuster votre fichier `~/.ssh/config`. Apprenez à utiliser des valeurs pratiques pour contourner les délais d'expiration agressifs des pare-feu et des NAT, garantissant une connectivité stable et persistante, même sur des réseaux instables. Inclut également des recommandations pour l'utilisation de multiplexeurs comme `tmux` pour une résilience de session optimale.

37 vues

Bonnes Pratiques pour Prévenir les Problèmes de Délai d'Attente SSH

SSH (Secure Shell) est l'épine dorsale de l'administration système à distance, offrant une connectivité chiffrée et sécurisée. Cependant, peu de choses sont aussi frustrantes qu'une session qui se coupe de manière inattendue en raison d'un délai d'attente. Ces problèmes sont particulièrement fréquents sur les réseaux instables, les connexions acheminées via des dispositifs NAT agressifs, ou lorsque les sessions restent inactives pendant une certaine période.

Ce guide explore les ajustements de configuration essentiels — tant côté client que côté serveur — que les administrateurs système et les développeurs peuvent mettre en œuvre pour maintenir de manière proactive des sessions SSH stables. En tirant parti des mécanismes d'« keep-alive » intégrés, vous pouvez garantir que vos tâches critiques ne seront pas interrompues, même en période d'incertitude réseau ou d'inactivité.


Comprendre la Cause Profonde des Délais d'Attente SSH

Un délai d'attente 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. Il ne s'agit généralement pas du logiciel SSH lui-même, mais plutôt des dispositifs réseau intermédiaires (pare-feu, routeurs et tables NAT) qui éliminent agressivement les connexions inactives pour conserver les 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 tentera d'envoyer des données, le serveur ne les recevra jamais, ce qui entraîne un gel de la session et, finalement, une erreur de délai d'attente.

La solution consiste à configurer SSH pour qu'il envoie régulièrement des signaux de « keep-alive » (de petits paquets sans données), 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 délais d'attente consiste à configurer le client SSH pour qu'il envoie périodiquement un message de keep-alive au serveur. Ceci 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 à travers les redémarrages et les différentes sessions de terminal.

Créez ou modifiez votre fichier de configuration client, généralement situé à l'adresse ~/.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 de keep-alive toutes les 60 secondes si la connexion est inactive.
  • ServerAliveCountMax 3 : Si le client envoie 3 messages de keep-alive consécutifs sans recevoir de réponse du serveur, le client terminera la connexion. (Durée totale du délai d'attente : 60 secondes * 3 tentatives = 180 secondes).

Configuration via Ligne de Commande

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

ssh -o "ServerAliveInterval 60" user@remote_host

Conseil : Une valeur comprise entre 30 et 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 fixées autour de 5 minutes) mais pas si fréquente qu'elle génère une surcharge réseau excessive.

2. Solutions Côté Serveur : Imposer 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 imposer des paramètres de keep-alive de manière centralisée ou définir des limites strictes pour les connexions inactives. Ceci se fait dans le fichier de configuration du démon SSH, /etc/ssh/sshd_config.

Utilisation de ClientAliveInterval et ClientAliveCountMax

Ces directives sont les homologues 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 :

    bash sudo nano /etc/ssh/sshd_config

  2. Ajoutez ou modifiez les lignes suivantes :

    ```config

    Le serveur enverra un paquet nul si aucune donnée n'est reçue du client pendant 300 secondes (5 minutes)

    ClientAliveInterval 300

    Si ClientAliveInterval est déclenché 0 fois sans réponse, déconnexion.

    Le régler à 0 signifie que le serveur se déconnecte immédiatement après la première vérification échouée.

    ClientAliveCountMax 0
    ```

Note sur ClientAliveCountMax :

Si vous réglez ClientAliveCountMax sur un nombre faible (comme 0 ou 1), le serveur appliquera un délai d'inactivité strict. Par exemple, ClientAliveInterval 300 et ClientAliveCountMax 0 signifient que si un utilisateur est complètement inactif pendant 5 minutes, le serveur supposera que la connexion est morte et forcera une déconnexion. Ceci est utile pour la sécurité mais peut être frustrant pour les utilisateurs. Si votre objectif est d'empêcher les pare-feu de couper la connexion, la définition d'une valeur ici est souvent secondaire par rapport au ServerAliveInterval côté client.

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

    ```bash
    sudo systemctl restart sshd

    ou

    sudo service sshd restart
    ```


3. Stratégies de Résilience Avancées

Bien que les keep-alives SSH gèrent les courtes périodes d'inactivité, une interruption complète du réseau (par exemple, changer de réseau Wi-Fi ou perdre momentanément le signal) interrompra toujours 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 coupures de connexion. Ils exécutent une session sur le serveur distant qui persiste même si votre connexion client est interrompue. 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 étiez arrêté.

Flux de travail tmux de base :

  1. Connectez-vous au serveur :
    bash ssh user@remote_host
  2. Démarrez une nouvelle session tmux sur le serveur :
    bash tmux new -s my_session
  3. Travaillez à l'intérieur de la session tmux.
  4. Si la connexion se coupe, 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 :
    bash tmux attach -t my_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 au niveau SSH (ServerAliveInterval) sont généralement préférés car :

  1. Portabilité : Les directives SSH fonctionnent de manière cohérente, quelle que soit la configuration du noyau du système d'exploitation sous-jacent.
  2. Couche Application : Les keep-alives SSH fonctionnent au sein de la couche application, garantissant que le démon SSH reste réactif.
  3. Sensibilité au Pare-feu : Les keep-alives TCP peuvent parfois être bloqués silencieusement 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, n'oubliez pas que le réglage réel de l'intervalle est contrôlé par le système d'exploitation (par exemple, net.ipv4.tcp_keepalive_time sous Linux), et non par la configuration SSH.

Résumé des Bonnes Pratiques

Problème Directive de Configuration Emplacement Valeur Recommandée Objectif
Délais d'attente Client ServerAliveInterval ~/.ssh/config (Client) 30 - 60 secondes Envoie des paquets nuls du client au serveur pour empêcher la coupure 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 la Connexion N/A Session Serveur tmux ou screen Permet la persistance de la session malgré une défaillance réseau.

En implémentant la directive ServerAliveInterval sur vos machines clientes, vous résoudrez la grande majorité des problèmes de délai d'attente SSH causés par l'inactivité du réseau. Pour les tâches critiques, la superposition de cette configuration avec un multiplexeur de session offre une immunité quasi totale contre les interruptions de connexion.