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é.
-
Ouvrez le fichier de configuration du démon SSH :
bash sudo nano /etc/ssh/sshd_config -
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.
-
Redémarrez le service SSH pour que les modifications prennent effet :
```bash
sudo systemctl restart sshdou
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 :
- Connectez-vous au serveur :
bash ssh user@remote_host - Démarrez une nouvelle session
tmuxsur le serveur :
bash tmux new -s my_session - Travaillez à l'intérieur de la session
tmux. - Si la connexion se coupe, ou si vous devez partir, détachez la session (Ctrl+B, puis D).
- Reconnectez-vous au serveur via SSH.
- 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 :
- Portabilité : Les directives SSH fonctionnent de manière cohérente, quelle que soit la configuration du noyau du système d'exploitation sous-jacent.
- Couche Application : Les keep-alives SSH fonctionnent au sein de la couche application, garantissant que le démon SSH reste réactif.
- 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.