ハクソク

世界を動かす技術を、日本語で。

SSHはなぜキー入力ごとに100パケットを送信するのか？

2026年1月23日原文(eieio.games)

概要

  • SSHセッション での パケット通信量 の増加原因調査
  • Keystroke timing obfuscation による 大量の“chaff”パケット 発生
  • ゲームサーバー での パフォーマンス低下 とその対処法
  • Goのsshライブラリ を フォークして拡張機能を無効化 し大幅な改善
  • LLMによるデバッグ支援 の体験と考察

SSHセッションとパケット量の謎

  • tcpdump でSSHセッションを解析した結果、 1回のキーストローク で非常に多くのパケットが送信される現象を確認
  • 36バイトのデータパケット が多数、 0バイトのACKパケット が約3割、 ごく少数の他サイズパケット が観測
  • 1つのキーストローク で 約90パケット/秒 という高頻度通信を記録

実験環境と問題発見

  • 高性能ゲーム を ssh経由 で動作させ、 bubbletea と wish を利用したTUIを実装
  • 数百のbot をssh接続し、 1秒ごとに操作 させてパフォーマンス計測
  • テスト中に 「your screen is too small」 という1回のメッセージのみ送信する状態となり、 CPU・帯域使用量が半減
  • ゲームデータ未送信でもCPUが0%にならない ことに違和感を覚え、詳細調査へ

詳細調査とtcpdumpの分析

  • ゲームデータ送信時 と 送信停止時 のパケットキャプチャを比較
  • 送信停止時でも36バイトパケットが20ms間隔で大量発生 していることが判明
  • MacOSの標準sshクライアント で同様のパターンを再現確認

原因の特定：Keystroke Timing Obfuscation

  • ssh -vvv でログを確認し、 obfuscate_keystroke_timing 機能が 20ms間隔でchaffパケット を送信していることを発見
  • 2023年以降のssh で導入された Keystroke Timing Obfuscation が原因
    • タイピング速度から入力内容を推測されるリスク を低減するため、 ダミーパケット（chaff） を大量送信
  • ゲーム用途 では 大量の無駄な通信とCPU負荷 の原因

対策と効果

  • sshクライアント側 で ObscureKeystrokeTiming=no を指定するとchaff送信が停止し、 CPU・帯域が大幅削減
  • Goのsshライブラリ （crypto/ssh）で [email protected]拡張の広告を停止 するパッチを作成
    • SSH2_MSG_PING メッセージを送らせないことでchaff通信を根本的に防止
  • パッチ適用後の効果
    • CPU使用率 ：約30%→11%
    • システムコール時間 ：3.1s→0.66s
    • 暗号処理時間 ：1.6s→0.11s
    • 帯域 ：6.5Mbit/sec→3Mbit/sec
  • フォーク運用のリスク はあるが、 劇的なパフォーマンス向上 を実現

LLMによるデバッグ体験

  • Claude Code などのLLMを活用し、 tcpdumpやtsharkの出力解釈 を迅速化
  • LLMの提案 と自分の知識を組み合わせて問題解決
  • ChatGPT の誤った提案も経験し、 LLMとの対話力や試行錯誤の重要性 を再認識
  • LLMは万能ではないが、強力な補助ツール として活用できる実感

まとめ

  • SSHのKeystroke Timing Obfuscation は セキュリティ向上 には有効だが、 高頻度通信が必要な用途 では 大きなオーバーヘッド
  • Goのsshライブラリの拡張広告を止めることで根本解決 が可能
  • LLMを活用したデバッグ は、知識の補完や効率化に有効
  • 実践的な問題解決力と新しいツールの習熟 が今後ますます重要

Hackerたちの意見

あの20msは決定的な証拠だね。さっき見た謎のパターンとぴったり一致してる！それはさておき、クラウドがその「決定的な証拠」って言葉を使いすぎじゃない？デバッグの質問をすると、バージョン番号とか何かランダムなことを「決定的な証拠」って言う気がする。

└

決定的な証拠、まさにその通りだね。いい質問だし、エムダッシュ、「fooだけじゃなくて、barもある」って、本当の真実、厳しい真実、問題を浮き彫りにして、掘り下げて、またエムダッシュ… もう気持ち悪いよ。

└

それについて掘り下げてみたいな。 https://pshapira.net/2024/03/31/delving-into-delve/

└

LLMのパーソナリティ調整がどうなってるか分からないけど、興奮しやすさ（興奮したフレーズを使う傾向）が強くなってるんじゃないかな。「決定的な証拠」っていう言葉は、興奮度が高い評価を受けてるはず。他にも「素晴らしい！」や「いい発見！」、「その通り！」みたいなフレーズにも当てはまると思う。

└

ChatGPTもそうだよね。「ぴったり一致してる」って言うけど、実際には何とも一致してないし。

└

クロードは私との会話でこれを一度も使ったことがないと思う（Claude Desktop、Claude Code、音声会話...）。お世辞、確かに！もしかしたら、あなたのプロフィールや記憶に関係があるのかも？

└

はい！この投稿は完全に私が書いたけど、昨夜クレードとデバッグにかなりの時間をかけたから、「スモーキングガン」を用意してたとしても驚かないな。

└

特定のフレーズやmdashesをよく見るかもしれないけど、…これらのプログラムは人間が書いたデータ（またはマイクロソフトのスペル修正）で訓練されてるから、過去数年でそれを使いすぎたんじゃないかな？じゃあ、これらの可哀想なLLMたちは代わりに何を生成すればいいの？

└

それとも「ユーレカ！それはただのスモーキングガンじゃなくて、LLMspeakの典型的なケースだ。」って感じかな。Grok、ChatGPT、Claudeはみんなこういう癖があって、プロ版でも回答の中でその特徴的なフレーズを何度も使うんだ。これが意図的なのか、AIを検出しやすくするためなのか、ちょっと気になるね。

└

ちょっとしたSREエージェントを作って、オンコールのためにチケットに情報を事前に入れようとしてるんだけど、もうClaudeが「決定的証拠」を見つけるのに疲れちゃった。

└

彼らはクリシェが大好きで、同じ言葉を繰り返すのが嫌いだから、「原因」とか言った後に「決定的証拠」って言ったり、また別の何かに変わったりするんだよね。

TCP_CORKを使うと、遅延を増やさずにパケット数を減らせるよ。TCP_NODELAYを無効にするのもパケット数を減らせるし、ポータブルで実装も簡単だけど、遅延のペナルティが発生するね。

Hacker Newsで議論の続きを見る