Réglages avancés SSH : Optimiser la configuration côté client pour les réseaux à faible bande passante

SSH devient pénible sur les liaisons lentes lorsque les sessions se figent, les transferts de ports échouent ou que chaque nouvelle connexion prend plusieurs secondes. Quelques paramètres côté client dans ~/.ssh/config peuvent rendre ces liaisons plus stables sans modifier le serveur.

Nous allons explorer des paramètres critiques tels que ServerAliveInterval et TCPKeepAlive, comprendre leurs rôles distincts et apprendre à les utiliser efficacement. Au-delà des keep-alives de base, nous aborderons également d'autres techniques d'optimisation puissantes comme la compression, le multiplexage de connexions et la sélection intelligente de chiffrements. À la fin de ce guide, vous aurez une compréhension complète de la façon de configurer votre client SSH pour maintenir des sessions stables et performantes, rendant votre travail à distance nettement plus efficace et fiable.

Comprendre les défis de performance SSH

Des conditions réseau médiocres se manifestent de plusieurs manières lors de l'utilisation de SSH :

• Connexions interrompues : Les sessions se terminent de manière inattendue, vous obligeant à vous reconnecter et risquant de perdre un travail non sauvegardé ou l'état d'un processus.
• Sessions interactives lentes : Les commandes prennent nettement plus de temps à s'exécuter et la frappe semble lente, réduisant la productivité.
• Transferts de fichiers retardés : Les opérations scp ou sftp rampent, ou pire, échouent en cours de transfert.
• Sessions figées : Le terminal peut cesser de répondre pendant de longues périodes, rendant incertain si la connexion est active ou morte.

Ces problèmes proviennent souvent d'intermédiaires réseau (routeurs, pare-feu, dispositifs NAT) qui suppriment silencieusement les connexions inactives, ou simplement des délais et pertes de paquets inhérents aux liaisons peu fiables. SSH propose des mécanismes côté client pour lutter contre ces problèmes.

Paramètres clés de réglage côté client

Deux paramètres fondamentaux aident à maintenir la stabilité des sessions SSH en envoyant des messages "keep-alive" périodiques :

ServerAliveInterval et ServerAliveCountMax

Ces options fonctionnent au niveau du protocole SSH. Elles demandent au client SSH d'envoyer un paquet nul (un petit message chiffré qui ne fait rien d'autre que signifier une activité) au serveur si aucune donnée n'a été reçue du serveur pendant une durée spécifiée.

• ServerAliveInterval : Spécifie le délai d'attente en secondes après lequel le client enverra un paquet nul au serveur si aucune donnée n'a été reçue du serveur. Cela empêche les connexions d'expirer en raison d'une inactivité du côté serveur.
• ServerAliveCountMax : Définit le nombre de messages ServerAliveInterval qui peuvent être envoyés sans obtenir de réponse du serveur. Si cette limite est atteinte, le client se déconnectera du serveur, supposant que la connexion est morte.

Exemple de configuration :

# ~/.ssh/config
Host monhotedistant
    HostName votre.serveurdistant.com
    User votre_nom_utilisateur
    ServerAliveInterval 60  # Envoyer un keep-alive toutes les 60 secondes si inactif
    ServerAliveCountMax 3   # Se déconnecter après 3 keep-alives sans réponse (180 secondes au total)

Explication : Avec ServerAliveInterval 60 et ServerAliveCountMax 3, votre client SSH enverra un paquet keep-alive toutes les 60 secondes si la session est inactive. Si le serveur ne répond pas à 3 keep-alives consécutifs (soit un total de 180 secondes de non-réponse), le client mettra fin à la connexion de manière gracieuse. Cela vous évite de rester bloqué dans un terminal figé, à attendre indéfiniment.

TCPKeepAlive

TCPKeepAlive fonctionne au niveau du protocole TCP, distinct des keep-alives au niveau SSH. Lorsqu'il est activé, il demande au système d'exploitation d'envoyer des sondes keep-alive TCP sur la connexion TCP sous-jacente si aucune donnée n'a été échangée pendant une période spécifique. Il s'agit d'un paramètre système, mais SSH peut l'activer ou le désactiver pour ses connexions.

• TCPKeepAlive : Une option booléenne (yes ou no). Si elle est définie sur yes, le mécanisme keep-alive TCP du système est utilisé pour vérifier si la connexion est toujours active.

Exemple de configuration :

# ~/.ssh/config
Host monhotedistant
    HostName votre.serveurdistant.com
    User votre_nom_utilisateur
    TCPKeepAlive yes # Activer les keep-alives TCP pour cette connexion

Explication : Par défaut, SSH a généralement TCPKeepAlive yes activé. Bien que ServerAliveInterval soit généralement préféré pour les sessions SSH car il fonctionne dans le canal SSH chiffré, TCPKeepAlive peut servir de solution de repli de bas niveau, particulièrement utile dans des environnements réseau très agressifs qui pourraient interrompre même des connexions TCP apparemment actives.

Lequel utiliser ?

• ServerAliveInterval est généralement préféré pour SSH. Il fonctionne dans le protocole SSH, ce qui signifie que les paquets keep-alive sont chiffrés et traités par le démon SSH, les rendant plus robustes face aux intermédiaires réseau qui pourraient interférer avec les paquets TCP bruts. Il vous donne également un contrôle plus précis sur la vivacité de la session SSH.
• TCPKeepAlive peut être une bonne mesure secondaire ou pour des problèmes réseau très spécifiques. Comme il est géré par le système d'exploitation, ses paramètres de temporisation (fréquence d'envoi des sondes, nombre avant déconnexion) sont généralement configurés au niveau système et ne sont pas directement contrôlables par les paramètres du client SSH.
• Utiliser les deux simultanément est souvent redondant mais inoffensif. ServerAliveInterval détectera généralement les problèmes et agira avant TCPKeepAlive en raison de ses intervalles par défaut souvent plus courts (ou d'intervalles définis par l'utilisateur plus courts).

Au-delà des keep-alives de base : Autres techniques d'optimisation

Bien que les keep-alives évitent les déconnexions, d'autres paramètres peuvent améliorer considérablement les performances sur les liaisons à faible bande passante.

Compression (Compression yes)

SSH offre une compression intégrée utilisant zlib (ou [email protected]). Lorsqu'elle est activée, les données sont compressées avant d'être envoyées sur le réseau et décompressées à la réception. Cela peut réduire la taille des transferts pour les sessions à forte teneur en texte, bien que cela n'aide pas pour les données déjà compressées comme les archives, les images ou les vidéos.

Quand l'utiliser :

• Connexions à faible bande passante : Le cas d'utilisation principal. Moins de données signifie une vitesse perçue plus rapide.
• Transfert de données hautement compressibles : Fichiers texte, journaux, code source, images non compressées, etc.

Quand être prudent :

• Connexions à haute bande passante et haute latence : La surcharge CPU de la compression/décompression pourrait annuler les avantages de la réduction des données, surtout si les données sont déjà efficacement compressées (par exemple, images JPEG, fichiers ZIP).

Exemple de configuration :

# ~/.ssh/config
Host hoteabasdebit
    HostName votre.serveurdistant.com
    User votre_nom_utilisateur
    Compression yes

Multiplexage de connexions (ControlMaster, ControlPath, ControlPersist)

Le multiplexage de connexions permet à plusieurs sessions SSH vers le même hôte de partager une seule connexion TCP sous-jacente. C'est extrêmement utile lorsque vous ouvrez fréquemment de nouvelles sessions SSH, transférez des fichiers avec scp ou utilisez git via SSH vers le même serveur.

Avantages :

• Connexions ultérieures plus rapides : Plus besoin de poignées de main TCP répétées ou d'authentification SSH.
• Utilisation réduite des ressources : Moins de connexions TCP, moins de surcharge.
• Authentification unique : Vous vous authentifiez (par exemple, en entrant un mot de passe ou une phrase de passe) uniquement pour la première connexion.

Exemple de configuration :

# ~/.ssh/config
Host *
    ControlMaster auto
    ControlPath ~/.ssh/control/%r@%h:%p
    ControlPersist 1h # La connexion maître persiste pendant 1 heure après la fermeture du dernier client

Explication :

• ControlMaster auto : Active le multiplexage. Si une connexion maître existe, la réutiliser ; sinon, en créer une nouvelle.
• ControlPath ~/.ssh/control/%r@%h:%p : Spécifie le chemin vers le socket de contrôle. %r est l'utilisateur distant, %h est l'hôte, %p est le port. Cela garantit des sockets uniques pour différentes connexions.
• ControlPersist 1h : Maintient la connexion maître ouverte pendant 1 heure même après la fermeture de toutes les sessions client qui la partagent. Autres valeurs utiles : no (ferme avec le dernier client), yes (maintient ouvert indéfiniment), ou une durée spécifique (par exemple, 5m pour 5 minutes).

Pour l'utiliser : La première fois que vous vous connectez (ssh monhotedistant), elle établit le maître. Les connexions ultérieures (ssh monhotedistant, scp fichier monhotedistant:.) réutiliseront instantanément le maître.

Sélection de chiffrement (Ciphers)

Différents chiffrements offrent des niveaux de sécurité et une charge de calcul variables. Sur les réseaux à faible bande passante et haute latence, choisir un chiffrement plus léger en calcul peut améliorer les temps de réponse interactifs.

Considérations :

• Chiffrements modernes et rapides : [email protected] et les variantes aesgcm (par exemple, [email protected]) sont souvent de bons choix car ils sont conçus pour la performance et la sécurité.
• Éviter les chiffrements obsolètes : Certains chiffrements plus anciens comme 3des-cbc sont plus lents et moins sécurisés.

Exemple de configuration :

# ~/.ssh/config
Host hotechiffrementrapide
    HostName votre.serveurdistant.com
    User votre_nom_utilisateur
    Ciphers [email protected],[email protected],[email protected]

Astuce : Priorisez toujours la sécurité. N'utilisez que des chiffrements pris en charge par votre serveur et préférez les chiffrements modernes et sécurisés, même s'ils sont légèrement plus lents, sauf si les performances sont gravement impactées.

Transfert d'agent (ForwardAgent yes)

Bien qu'il ne s'agisse pas directement d'un paramètre d'optimisation des performances réseau, ForwardAgent yes améliore considérablement l'expérience utilisateur et l'efficacité sur les hôtes distants. Il vous permet d'utiliser votre agent SSH local pour vous authentifier sur d'autres serveurs à partir de l'hôte distant sans avoir vos clés privées sur la machine distante. Cela évite les saisies répétées de mot de passe/phrase de passe, ce qui fait gagner du temps et améliore le flux de travail, en particulier sur les liaisons lentes.

# ~/.ssh/config
Host serveurintermediaire
    HostName saut.serveur.com
    User votre_nom_utilisateur
    ForwardAgent yes

Configuration pratique : ~/.ssh/config

Tous les paramètres discutés peuvent être placés dans votre fichier de configuration client SSH, généralement ~/.ssh/config. Vous pouvez appliquer les paramètres globalement ou par hôte.

Paramètres globaux : Appliqués à toutes les connexions SSH, sauf si remplacés par une entrée d'hôte spécifique.

Paramètres par hôte : Appliqués uniquement à l'Host spécifié. Utilisez Host * pour un joker correspondant à tous les hôtes.

# ~/.ssh/config exemple pour les réseaux à faible bande passante

# Paramètres globaux pour tous les hôtes (sauf si remplacés)
Host *
    TCPKeepAlive yes
    ControlMaster auto
    ControlPath ~/.ssh/control/%r@%h:%p
    ControlPersist 1h
    Compression no # Activer uniquement pour les hôtes spécifiques où cela aide

# Hôte spécifique optimisé pour faible bande passante
Host mon_serveur_lent
    HostName 192.168.1.100
    User utilisateurdistant
    ServerAliveInterval 30 # Keep-alive agressif pour les liaisons très instables
    ServerAliveCountMax 5
    Compression yes       # Activer la compression pour cet hôte spécifique
    Ciphers [email protected],[email protected]
    ForwardAgent yes      # Si vous devez sauter depuis ici

# Un autre hôte, paramètres moins agressifs
Host autre_serveur
    HostName exemple.com
    User votrenom
    ServerAliveInterval 120 # Moins agressif pour les liaisons modérément stables
    ServerAliveCountMax 3

Permissions : Assurez-vous que votre fichier ~/.ssh/config a les bonnes permissions : chmod 600 ~/.ssh/config.

Dépannage et bonnes pratiques

• Commencez par les valeurs par défaut raisonnables : Ne réglez pas trop immédiatement. Commencez par ServerAliveInterval et Compression pour les hôtes problématiques.
• Surveillez et ajustez : Faites attention à la façon dont vos connexions se comportent. Si vous subissez encore des interruptions, essayez des valeurs ServerAliveInterval plus agressives (par exemple, 15 à 30 secondes).
• Considérations côté serveur : Si vous contrôlez le serveur SSH, envisagez de configurer ClientAliveInterval et ClientAliveCountMax dans /etc/ssh/sshd_config pour compléter les paramètres côté client. Cela garantit que le serveur vérifie également activement la vivacité du client.
• Sécurité vs Performance : Trouvez toujours un équilibre. Évitez de désactiver des fonctionnalités de sécurité essentielles pour des gains de performance marginaux. Par exemple, n'utilisez jamais de chiffrements obsolètes sauf en cas d'absolue nécessité pour des systèmes hérités, et même dans ce cas, comprenez les risques.
• Diagnostics réseau : Avant de modifier SSH, confirmez la connectivité réseau de base et la latence à l'aide de ping ou mtr pour comprendre les conditions réseau sous-jacentes.
• ProxyJump pour les connexions multi-sauts : Si vous devez traverser plusieurs hôtes, ProxyJump peut simplifier votre configuration et est généralement plus efficace que d'enchaîner des commandes ssh -A.

À retenir

Commencez par les keepalives et le multiplexage de connexions car ils améliorent la stabilité et les connexions répétées avec peu d'inconvénients. Ajoutez la compression pour les sessions à forte teneur en texte sur les liaisons lentes, et modifiez les chiffrements uniquement lorsque vous avez mesuré un véritable goulot d'étranglement ou devez satisfaire une politique de sécurité spécifique.