Alasan SSH mengirim 100 paket untuk setiap penekanan tombol

 (eieio.games)
9 poin oleh GN⁺ 2026-01-23 | 1 komentar | Bagikan ke WhatsApp
  • Ditemukan kasus ratusan paket terkirim untuk satu penekanan tombol dalam sesi SSH, lalu akar penyebabnya ditelusuri
  • Hasil analisis tcpdump menunjukkan sebagian besar paket berupa pesan berulang berukuran 36 byte, muncul tiap sekitar 20ms
  • Penyebabnya adalah fitur "keystroke timing obfuscation" yang ditambahkan ke SSH pada 2023; untuk menyembunyikan timing input pengguna, fitur ini mengirim banyak paket "chaff" (SSH2_MSG_PING)
  • Dengan menonaktifkan fitur ini atau mengubah server agar tidak mengiklankan ekstensi [email protected], penggunaan CPU dan bandwidth turun hingga kurang dari setengah
  • Ini menunjukkan bahwa fitur keamanan SSH dapat menjadi beban besar pada aplikasi yang membutuhkan performa real-time, seperti game

Penemuan masalah

  • Saat menguji TUI game berperforma tinggi yang berjalan melalui SSH, ditemukan bahwa satu penekanan tombol saja dapat memicu 270 paket
    • Hasil tcpdump: 66% berupa pesan 36 byte, 33% TCP ACK, sisanya sejumlah kecil data lain
    • Rata-rata 90 paket/detik, dengan pengiriman data tiap sekitar 11ms
  • Saat pengujian, server sempat salah dikonfigurasi sehingga hanya mengirim pesan "your screen is too small"; pada kondisi ini penggunaan CPU dan bandwidth turun setengah
    • Karena data game seharusnya tidak dikirim, penggunaan CPU idealnya mendekati 0%, tetapi ternyata masih bertahan di sekitar 50%
    • Dari sini muncul dugaan adanya overhead komunikasi dari SSH itu sendiri

Proses investigasi

  • Menggunakan tcpdump untuk membandingkan trafik SSH antara kondisi normal dan kondisi error
    • Bahkan pada kondisi error, paket 36 byte tetap terus muncul tiap 20ms
    • Pola yang sama juga ditemukan pada klien SSH bawaan MacOS
  • Hasil analisis file pcap dengan Claude Code menunjukkan
    • Dari total 413.703 paket, 66% berukuran 36 byte dan 34% berupa ACK 0 byte
    • Klien SSH-lah yang secara aktif membuat paket-paket tersebut

Akar penyebab

  • Pada log debug SSH (ssh -vvv), ditemukan pesan berikut 
    obfuscate_keystroke_timing: starting: interval ~20ms
obfuscate_keystroke_timing: stopping: chaff time expired (101 chaff packets sent)
    • Interval 20ms dan puluhan hingga lebih dari seratus paket chaff sesuai dengan pola yang benar-benar diamati
  • Penyebabnya adalah fitur obfuscation timing penekanan tombol yang ditambahkan ke SSH pada 2023
    • Untuk mencegah pola kecepatan mengetik pengguna terekspos, fitur ini mengirim paket "chaff" acak
    • Berguna untuk keamanan, tetapi di lingkungan yang sensitif terhadap latency, fitur ini menimbulkan beban berlebihan

Solusi

  • Di sisi klien, fitur dapat dinonaktifkan dengan opsi ObscureKeystrokeTiming=no
    • Setelah diterapkan, penggunaan CPU dan bandwidth turun signifikan, sementara transmisi data tetap normal
  • Sebagai penanganan di sisi server, ekstensi [email protected] dihapus dari iklan kemampuan pada library SSH Go
    • Setelah commit terkait dibatalkan dan diuji ulang, hasilnya:
      • Penggunaan CPU 29.9% → 11.6%,
        system call 3.10s → 0.66s,
        operasi kriptografi 1.6s → 0.11s,
        bandwidth 6.5Mbit/s → 3Mbit/s
    • Performa meningkat lebih dari 50%

Pengalaman debugging dengan bantuan LLM

  • Dengan Claude Code, analisis tcpdump dan tshark dapat diotomatisasi sehingga akar masalah lebih cepat dipersempit
    • Karena proses eksekusi perintah bisa diamati secara real time, mental model tetap terjaga
  • ChatGPT sempat salah menilai perilaku SSH sebagai sesuatu yang "normal", sehingga terlihat juga perbedaan antar model
  • LLM memang tidak menggantikan seluruh proses pemecahan masalah, tetapi terbukti sangat efisien sebagai alat bantu analisis
  • Ini menjadi contoh penyelesaian masalah performa jaringan yang kompleks melalui kombinasi penalaran manusia dan analisis LLM

Bacaan terkait

1 komentar

 
GN⁺ 2026-01-23
Komentar Hacker News

  • Mem-fork library crypto milik Go terasa agak menakutkan
    Saya sedang memikirkan cara agar patch kecil saya tetap aman
    Sebenarnya saya rasa fitur seperti ini seharusnya di-upstream sebagai opsi di library ssh
    Di lingkungan yang tidak tepercaya, mengirim paket chaff (noise) sebagai default itu bagus, tetapi sering juga ada kebutuhan untuk menghemat bandwidth

    • Mengontrolnya dengan cara yang tidak mengiklankan fitur tersebut adalah pendekatan yang tidak stabil
      Solusi yang benar adalah menambahkan opsi agar server bisa memberi sinyal ke klien bahwa ini “tidak diperlukan”, lalu klien bisa menerimanya atau memberi peringatan
    • Sebenarnya perilaku serupa sudah ada
      Ini hanya berlaku untuk sesi TTY, dan klien bisa menonaktifkannya
      Hanya saja, kasus ini merupakan situasi yang tidak biasa karena server sudah tahu sebelumnya bahwa koneksi ini tidak penting
      Dalam kebanyakan kasus, klien mengharapkan pengaturan ObscureKeystrokeTiming tetap dipatuhi
    • Meski begitu, saya rasa perubahan ini kemungkinan akan ditolak
      library crypto adalah codebase yang sangat berpandangan kuat, sampai urutan TLS cipher suite pun dibuat tidak bisa diubah
    • Bahkan di lingkungan tepercaya pun ancaman tetap ada
      Ini tampak seperti kasus penggunaan SSH yang sangat khusus
      Jika diekspos terlalu luas, bisa muncul situasi “setel lalu lupakan” yang justru melemahkan keamanan
    • Dulu ada masa memakai ZX80 dengan RAM 1KB
      Ada juga masa berkomunikasi lewat modem 1200bps, dan modem 56K pada dasarnya agak dilebih-lebihkan
      Sekitar tahun 1994 saya bekerja di akademi militer Inggris dan pertama kali melihat WWW, saat itu saya berpikir “kok kurang menarik ya”
      Kalau dipikir sekarang, perubahan zaman memang luar biasa

  • Ini pertama kalinya saya mendengar fitur obfuscation ini, menarik juga
    Saat men-debug perilaku ssh, mem-patch cipher “None” untuk melihat isi paket secara langsung juga bisa jadi cara yang bagus
    Kalau ini game terminal yang mengutamakan performa dan keamanan tidak penting, mungkin layak mempertimbangkan memakai telnet saja

  • Saya tidak tahu SSH melakukan hal seperti ini
    Saya paham kenapa ini aktif secara default, tetapi di lingkungan saya sepertinya lebih tepat dimatikan

    1. Saya hampir tidak pernah mengetik rahasia langsung lewat SSH
    2. Tidak ada alasan penyerang level negara mengendus input keyboard saya
    3. Ini koneksi antarbenua jadi penghematan bandwidth penting
      Jadi saya ingin mengatur ObscureKeystrokeTiming=no. Apakah ada alasan kenapa saya sebaiknya tidak melakukan itu?
    • Sikap keamanan yang terlalu optimistis itu berbahaya
      (1) Sulit selalu membedakan kapan seseorang sedang memasukkan rahasia, dan seluruh aktivitas bisa dianalisis polanya
      (2) Ini serangan yang bahkan bisa dilakukan di level laboratorium universitas — lihat makalah USENIX dan contoh riset
      (3) Di internet yang didominasi trafik video, tidak ada artinya mengorbankan keamanan demi menghemat beberapa byte input keyboard
    • Rahasia yang paling sering diketik pada koneksi tty SSH adalah kata sandi sudo
      Jika penyerang menganalisis timing input keyboard, mereka mungkin bisa memperkirakan perintah dan pola kata sandi yang terenkripsi
      Tentu saja dekripsi akan sulit karena kunci sesi selalu berubah, tetapi tetap ada kemungkinan
      Saya sendiri menyalin-tempel sebagian besar kata sandi dari password manager
    • Anda tidak bisa yakin bahwa plaintext apa pun yang bocor tidak akan berguna bagi penyerang
      Kebanyakan orang merasa tidak ada masalah meskipun mematikan fitur keamanan SSH, tetapi itu hanya karena mereka beruntung
      Jika benar-benar butuh performa, pakai Telnet; jika benar-benar butuh keamanan, kombinasi ContainerSSH + OAuth2 lebih baik

  • Pada 2004 saya pernah meneliti analisis jeda antar penekanan tombol pada sesi SSH untuk menebak perintah
    Lihat materi analisis saat itu
    Patch tahun 2023 pada akhirnya menyelesaikan masalah itu

    • Saya ingat Dug Song dan Solar Designer mempresentasikan analisis timing SSH di konferensi peretasan HAL2001
      Materi presentasi
      Waktu benar-benar berlalu cepat

  • Saya kurang yakin Claude benar-benar membantu untuk debugging
    Penulis tampaknya sudah tahu arahnya, dan Claude terasa cuma mengiyakan saja
    Claude mengatakan hal seperti “Holy Cow!” itu agak mengganggu

    • Tapi kalau itu membantu merapikan pikiran seperti Rubber Duck Debugging, tetap ada nilainya
      Saat saya men-debug perilaku sistem dengan Claude, meskipun tidak memberi jawaban langsung, itu membantu merapikan pemahaman dan menjaga motivasi
      Wiki Rubber Duck Debugging
    • Claude jauh lebih cepat daripada saya dalam ekstraksi field pcap atau pemrosesan awk
    • AI unggul dalam mendeteksi kepribadian dari teks
      Melihat penulis suka dengan reaksi “holy cow” dan memasukkannya ke blog, tampaknya Claude cukup pandai membaca suasana
    • Mungkin bukan ide bagus memberi kepribadian pada alat pengembangan

  • Dengan TCP_CORK, Anda bisa mengurangi jumlah paket tanpa menambah latensi
    Mematikan TCP_NODELAY juga bisa, tetapi ada harga berupa peningkatan latensi

    • Saya baru pertama kali mendengar TCP_CORK, menarik juga
      Jika socket di-cork, kernel akan men-buffer data lalu mengirimkannya saat di-uncork atau ketika mencapai MSS
      Jadi ini cara untuk menggabungkan paket saat transmisi
      Referensi
    • Saya tidak tahu soal TCP_CORK, tetapi ini terlihat sangat berguna
      Ping masih akan diterima seperti biasa, tetapi jumlah pengiriman pong mungkin bisa dikurangi
      Saya sudah pernah memakai TCP_NODELAY, tetapi latensinya jadi terlalu besar untuk game saya
      Posting HN sebelumnya
    • Namun karena paket chaff dikirim setiap 20ms, saya ragu TCP_CORK bisa menggabungkannya
      Untuk tujuan obfuscation, coalescing latensi tampaknya tidak memungkinkan

  • Ungkapan “The smoking gun!” itu lucu
    Saya bukan penutur asli bahasa Inggris, tetapi saya pertama kali mempelajarinya karena Claude sering memakainya
    Sekarang ini benar-benar menyebar seperti kata populer

  • Ketergantungan pada LLM agak disayangkan
    Ini sepertinya bisa diselesaikan lebih cepat hanya dengan melihat packet capture di Wireshark
    SSH dissector-nya sudah cukup matang

    • Saya juga tidak terlalu suka LLM, tetapi kalau melihat paket SSH di Wireshark, kebanyakan yang terlihat hanya paket terenkripsi jadi tidak banyak informasi berguna
      Bahkan jika menangkap satu penekanan tombol dengan tcpdump, hasilnya bisa ratusan paket terenkripsi
      Pada akhirnya, berkat LLM penulis mempelajari sesuatu yang menarik dan membagikannya, jadi tetap bermakna
    • SSH dissector tidak sempurna
      Setelah pesan NEWKEYS, parsing tidak berjalan, dan bahkan jika dipatch dengan enkripsi none, alurnya tetap tidak sepenuhnya bisa diinterpretasikan
      Masih ada ruang untuk perbaikan
    • Sikap “cukup lihat Wireshark saja” terdengar seperti gatekeeping
      Belajar dengan memanfaatkan alat juga sudah cukup bernilai
    • SSH sejak namanya saja adalah protokol keamanan
      Sulit mendapatkan informasi yang bermakna hanya dari packet capture sederhana
    • Penulis tidak tahu soal penganalisis paket SSH, dan sebagai gantinya hanya memakai alat umum (LLM)
      Saya tidak paham kenapa itu harus dianggap sesuatu yang disayangkan

  • Pada 2023 SSH menambahkan fitur obfuscation timing penekanan tombol
    Karena karakter bisa ditebak dari kecepatan pengetikan, SSH mencampurkan paket chaff agar penyerang tidak bisa membedakannya
    Tetapi ini tampak seperti pendekatan yang keliru
    Kalau memang mau, semua penekanan tombol bisa dikirim dengan interval 50ms

    • Jeda 50ms tampaknya akan terasa sangat tidak nyaman saat mengetik
    • Tidak jelas apakah maksud “dikirim setiap 50ms” itu mengubah 20ms menjadi 50ms, atau pengiriman berkala terus-menerus
      Implementasi saat ini mengelompokkan dalam unit 20ms, lalu menghentikan pengiriman chaff jika tidak ada input selama waktu tertentu

  • Inti SSH adalah keamanan, tetapi jika keamanan tidak dibutuhkan, saya jadi bertanya kenapa masih memakai SSH
    Misalnya netcat(nc) sudah terpasang secara default di sebagian besar platform

    • Hanya karena “keamanan prioritas utama” bukan berarti itu satu-satunya hal
      Di SSH juga ada pertimbangan lain seperti performa dan kenyamanan
      Penulis hanya mengatakan fitur obfuscation penekanan tombol (privasi) itu tidak perlu
      Mungkin dia tetap ingin enkripsi atau jaminan integritas tetap ada
      Artinya, sebagian besar fitur keamanan SSH tetap dipertahankan dan hanya sebagian kecil yang dimatikan
    • SSH sekarang juga sudah disertakan di Windows, jadi pernyataan “semua platform punya nc” itu tidak akurat