Pourquoi SSH envoie 100 paquets à chaque frappe

• Un cas d’analyse a mis au jour le phénomène suivant dans une session SSH : des centaines de paquets sont envoyés pour une seule frappe, puis la cause a été identifiée
• L’analyse avec tcpdump a montré que la plupart des paquets étaient des messages répétitifs de 36 octets, émis à un intervalle d’environ 20 ms
• La cause était la fonctionnalité de « keystroke timing obfuscation » ajoutée à SSH en 2023, qui envoie de nombreux paquets de « chaff » (SSH2_MSG_PING) pour masquer le timing de saisie de l’utilisateur
• En désactivant cette fonctionnalité ou en modifiant le serveur pour qu’il n’annonce plus l’extension [email protected], l’utilisation CPU et la bande passante chutent de plus de moitié
• Cet exemple montre qu’une fonctionnalité de sécurité de SSH peut devenir une charge importante dans les applications où les performances en temps réel sont critiques (par exemple les jeux)

---

Découverte du problème

• Lors de tests sur la TUI d’un jeu haute performance exécuté via SSH, il a été constaté qu’une seule frappe générait 270 paquets
  • D’après tcpdump, 66 % étaient des messages de 36 octets, 33 % des ACK TCP, et le reste une petite quantité d’autres données
  • En moyenne, 90 paquets/s étaient transmis, avec un intervalle d’environ 11 ms
• Pendant les tests, le serveur avait été mal configuré pour n’envoyer que le message « your screen is too small », et dans ce cas l’utilisation CPU et de la bande passante a été divisée par deux
  • Comme aucune donnée de jeu ne devait être transmise, l’utilisation CPU aurait dû être proche de 0 %, mais elle restait autour de 50 %
  • Cela a conduit à soupçonner un surcoût de communication propre à SSH

Enquête

• Comparaison du trafic SSH en fonctionnement normal et en état d’erreur à l’aide de tcpdump
  • Même en état d’erreur, des paquets de 36 octets continuaient à être émis toutes les 20 ms
  • Le même motif a été observé avec le client SSH par défaut de macOS
• L’analyse du fichier pcap avec Claude Code a montré que
  • sur un total de 413 703 paquets, 66 % faisaient 36 octets et 34 % étaient des ACK de 0 octet
  • c’était le client SSH qui générait activement les paquets

Cause profonde

• Le journal de débogage SSH (ssh -vvv) a affiché le message suivant

  obfuscate_keystroke_timing: starting: interval ~20ms
  obfuscate_keystroke_timing: stopping: chaff time expired (101 chaff packets sent)
  

  • L’intervalle de 20 ms et les dizaines à la centaine de paquets de chaff correspondaient au motif réellement observé
• La cause était la fonctionnalité d’obfuscation du timing des frappes ajoutée à SSH en 2023
  • Elle envoie des paquets de « chaff » aléatoires afin d’éviter que le schéma de vitesse de frappe de l’utilisateur ne soit exposé
  • Utile pour la sécurité, elle provoque toutefois une surcharge excessive dans les environnements où la latence est critique

Solution

• Côté client, la fonctionnalité peut être désactivée avec l’option ObscureKeystrokeTiming=no
  • Après application, l’utilisation CPU et la bande passante ont fortement diminué, tout en maintenant une transmission des données normale
• Côté serveur, une réponse a consisté à retirer l’annonce de l’extension [email protected] dans la bibliothèque SSH de Go
  • Après avoir annulé le commit concerné et relancé les tests, les résultats étaient les suivants
    • utilisation CPU 29.9 % → 11.6 %,
      appels système 3.10s → 0.66s,
      opérations de chiffrement 1.6s → 0.11s,
      bande passante 6.5Mbit/s → 3Mbit/s
  • Les performances se sont améliorées de plus de 50 %

Expérience de débogage avec un LLM

• Claude Code a permis d’automatiser l’analyse de tcpdump et tshark, ce qui a aidé à cerner rapidement la cause du problème
  • Il a aussi été possible de conserver un modèle mental du problème en observant l’exécution des commandes en temps réel
• ChatGPT a au contraire mal interprété le comportement de SSH en le jugeant « normal », ce qui a aussi mis en évidence des différences entre modèles
• Les LLM ne remplacent pas l’ensemble du processus de résolution, mais se montrent très efficaces comme outils d’analyse d’appoint
• Il s’agit d’un exemple où le raisonnement humain et l’analyse d’un LLM ont été combinés pour résoudre un problème complexe de performances réseau