SSH3 - Shell aman yang lebih cepat dan kaya fitur dengan HTTP/3

• SSH3 adalah protokol shell aman generasi berikutnya yang berjalan di atas HTTP/3, dan secara signifikan meningkatkan kecepatan koneksi sesi dibandingkan SSHv2 tradisional
• Melalui QUIC dan TLS 1.3, SSH3 membentuk kanal aman serta mendukung sistem autentikasi modern seperti OAuth 2.0 dan OpenID Connect
• Server dapat disembunyikan di balik jalur rahasia, sehingga lebih kuat terhadap serangan seperti port scanning, serta menyediakan fitur baru seperti UDP port forwarding dan QUIC multipath
• SSH3 sudah mengadopsi sejumlah fitur inti dari OpenSSH, tetapi saat ini masih dalam tahap eksperimental, sehingga tidak disarankan untuk diterapkan di lingkungan produksi nyata
• Karena banyak yang menilai nama SSH3 kurang tepat, draf standardisasinya telah diubah menjadi “Remote Terminals over HTTP/3”, dan proses penggantian nama sedang berlangsung

---

Ikhtisar proyek SSH3 dan pentingnya

• SSH3 adalah solusi open source yang merancang ulang protokol SSH lama agar sesuai dengan HTTP/3 dan teknologi web modern
  • Makna dari protokol koneksi SSH yang ada (RFC4254) direkonstruksi di atas HTTP/3 Extended CONNECT dan kanal QUIC+TLS 1.3
• Proyek ini diajukan sebagai draf Internet IETF draft-michel-remote-terminal-http3, dan menawarkan berbagai keunggulan seperti sangat mengurangi kecepatan koneksi sesi serta ekspansi metode autentikasi modern
• Dibanding implementasi SSH lain, proyek ini menonjol lewat ide-ide inovatif seperti penggunaan QUIC dan konfigurasi server tersembunyi

Fungsi dan karakteristik utama

• Koneksi sesi yang cepat
  • Jika koneksi SSHv2 tradisional rata-rata membutuhkan 5~7 kali bolak-balik jaringan, SSH3 hanya memerlukan 3 kali bolak-balik, sehingga sangat mengurangi latensi yang dirasakan pengguna
  • Latensi penekanan tombol tetap dipertahankan pada tingkat yang setara dengan sebelumnya
• Keamanan yang ditingkatkan
  • Berdasarkan TLS1.3, QUIC, dan autentikasi HTTP, SSH3 memanfaatkan protokol keamanan teruji yang sudah digunakan dalam e-commerce dan internet banking
  • Mendukung berbagai metode autentikasi seperti kunci publik berbasis RSA dan EdDSA/ed25519, serta OAuth 2.0 dan OpenID Connect
  • Login juga dimungkinkan dengan akun Google, Microsoft, dan Github
• Fitur untuk menyembunyikan server
  • Server ditempatkan di balik URL rahasia tertentu (misalnya https://192.0.2.0:443/M3MzkxYWMx...), dan hanya merespons ketika permintaan autentikasi datang ke URL tersebut
  • Untuk permintaan lainnya, server mengembalikan 404 Not Found, sehingga penyerang atau crawler di internet tidak dapat mengetahui keberadaan server
  • Namun, jalur rahasia bukan pengganti autentikasi, sehingga tetap disarankan menggunakan mekanisme autentikasi terpisah seperti kunci publik, kata sandi, atau OIDC
• Proyek eksperimental yang terus dikembangkan
  • Secara struktural masih memerlukan verifikasi keamanan yang andal, dan tidak disarankan untuk diterapkan pada server produksi
  • Saat ini komunitas sedang mengumpulkan umpan balik di lingkungan eksperimen atau jaringan tertutup
• Kompatibilitas OpenSSH dan fitur tambahan
  • Mendukung parsing ~/.ssh/authorized_keys dan known_hosts, integrasi ssh-agent, TCP/UDP port forwarding, serta Proxy Jump
  • Dengan dukungan UDP forwarding, SSH3 menyediakan jalur akses ke server berbasis UDP seperti layanan DNS, RTP, dan QUIC, menggunakan jalur QUIC datagram
  • Menyediakan autentikasi server setingkat HTTPS melalui sertifikat X.509
  • Autentikasi tanpa kunci (Keyless): dengan OpenID Connect, koneksi dapat dilakukan tanpa menyalin kunci publik, cukup menggunakan SSO perusahaan atau akun eksternal seperti Google/GitHub

Kesimpulan

• SSH3 adalah proyek open source eksperimental yang mengembangkan lingkungan SSH dengan menghadirkan protokol jaringan modern dan autentikasi modern
• SSH3 sangat meningkatkan kecepatan, fleksibilitas, dan keamanan, tetapi sebelum ada verifikasi yang memadai, penggunaan di produksi harus dilakukan dengan hati-hati
• SSH3 memberikan pengalaman pengguna yang mirip dengan OpenSSH, sekaligus kaya akan fitur baru.
• Dengan evaluasi keamanan yang memadai dan partisipasi komunitas, SSH3 berpotensi menjadi SSH generasi berikutnya

[GN⁺]

Komentar Hacker News

• Saya benar-benar tidak suka nama ssh3, jadi saya senang melihat di bagian paling atas repo tertulis, “SSH3 akan diganti namanya. Untuk saat ini, ini masih berupa SSH Connection Protocol (RFC4254) yang berjalan di atas HTTP/3 Extended connect, tetapi ada banyak perubahan yang diperlukan dan perbedaannya terlalu jauh dari SSH lama sehingga tidak bisa diintegrasikan dengan mudah. Draf spesifikasinya juga sudah diubah menjadi ‘Remote Terminals over HTTP/3’, dan kami butuh waktu untuk memikirkan nama permanen yang lebih baik”
  • Nama seperti ini terasa tidak cocok, seperti seseorang membuat repo bernama “Windows 12” atau “Linux 7”
  • Saya mengusulkan nama seperti Secure Hypertext Interactive TTY sebagai pengganti SSH3
  • Saya sempat berpikir bagaimana kalau SSH/3 saja (nuansa SSH + HTTP/3)
  • Thread ini benar-benar mahakarya perdebatan ‘bike-shedding’ yang sesungguhnya
  • Saya juga sempat berpikir mungkin SSH2/3 lumayan, karena kebanyakan tetap SSH2 tetapi berjalan di atas HTTP/3
• Ada pendapat bahwa SSH itu lambat, dan menurut pengalaman saya bottleneck terbesar ada pada penyiapan sesi. Entah karena PAM atau kebijakan OpenBSD, setiap kali tahap setup sesi terasa sangat lambat, baik saat koneksi SSH dipakai ulang maupun dibuat baru. Untuk sesi panjang tidak masalah, tetapi untuk sekadar menjalankan satu perintah sederhana selalu ada overhead, jadi saya juga kurang puas dengan performa Ansible, dan akhirnya membuat sendiri mini ansible untuk eksekusi perintah jarak jauh tanpa overhead sesi
• Awalnya saya ragu, ‘Masa ini benar-benar lebih cepat daripada SSH tradisional?’ tetapi setelah membaca README dan melihat bahwa yang lebih cepat hanya tahap pembuatan koneksi, sedangkan kecepatan aktual setelah tersambung sama saja, saya bisa memahaminya. Bahkan peningkatan sebesar ini pun tetap masuk akal
  • Sebenarnya bukan lebih cepat dalam arti itu. Saat satu koneksi SSH dipakai untuk meneruskan trafik beberapa port, muncul head-of-line blocking, dan protokol QUIC/HTTP3 bisa mengatasi masalah ini
  • Saya berani bertaruh protokol ini akan jauh lebih cepat daripada SSH di link berlatensi tinggi, karena berbasis UDP sehingga bisa terus mengirim data dalam jumlah besar tanpa menunggu ack; jadi saat scp file besar dari berbagai belahan dunia, saya berharap ada peningkatan kecepatan yang signifikan
  • Di atas VPN ini bisa benar-benar lebih cepat, karena tidak terkena jebakan “TCP di dalam TCP”
  • Keunggulan utama HTTP/3 dan QUIC secara keseluruhan memang pengurangan round trip dibanding sebelumnya, jadi sejalan dengan koneksi yang lebih cepat dibuat
• Penjelasannya adalah, “SSHv2 butuh sekitar 5–7 round trip untuk inisialisasi sesi, sedangkan SSH3 hanya butuh 3. Selama sesi aktual, latensi input (waktu antara penekanan tombol–respons) tetap sama.” Dari sudut pandang pengguna, saya tidak pernah terlalu terganggu dengan kecepatan koneksi, jadi saya kurang merasa tertarik. SSH juga punya stabilitas yang sudah teruji habis-habisan, dan alat baru seperti ini, meskipun mungkin benar-benar production-grade, tetap terasa berisiko untuk dipercaya
  • Tunnel UDP adalah fitur kuncinya, jauh lebih ringan daripada wireguard, dan ada juga hal seperti autentikasi OpenID
  • ‘Kecepatan koneksi’ selalu sedikit mengganggu saya. Terutama saat ingin langsung menjalankan perintah di remote, rasanya lambat sekali
  • Di ssh3, kemungkinan besar head-of-line blocking sudah teratasi, jadi kalau beberapa port atau koneksi dimultipleks dalam satu koneksi fisik, harusnya lebih cepat
  • Kalau butuh pengalaman pengguna yang mulus, saya merekomendasikan Mosh
• Saya tidak tahu kenapa rasanya menyedihkan melihat semua protokol lapisan aplikasi terserap ke http
  • Kalau alurnya benar-benar ke sana, itu memang terasa menyedihkan. Model khas HTTP terlalu membatasi sekaligus rumit untuk banyak kasus. Tetapi HTTP/2 dan QUIC (transport untuk HTTP/3) terlalu serbaguna, jadi istilah HTTP sendiri terasa makin kehilangan makna. Setidaknya QUIC cukup jelas diposisikan sebagai pengganti TCP
  • Sebenarnya saya melihat sisi positifnya: kalau semua protokol distandardisasi seperti ini, traffic shaping, sensor, dan sejenisnya jadi lebih sulit. Pada akhirnya kalau trafiknya HTTP, atau aliran byte acak (artinya tidak mencolok), pengawasan/pemblokiran jaringan jadi lebih sulit. Kalau membuat protokol baru, kecuali ISP memang memberi perlakuan khusus yang menguntungkan, menyamar sebagai HTTP adalah cara agar lalu lintas tetap lancar tanpa melambat
  • Fenomena seperti ini juga akibat kebiasaan tim keamanan perusahaan yang ingin memblokir atau menghalangi semua hal. Ya, saya bicara tentang tim yang memakai Zscaler atau mode TLS man-in-the-middle
  • Pemblokiran seperti ini juga muncul di Wi-Fi bandara dan hotel di seluruh dunia. Misalnya email tidak bisa terkirim lewat Apple Mail karena kebijakan perusahaan memblokir port 25. Dengan alasan mencegah spam, mereka juga memblokir 143, 587, 993, dan lain-lain, sehingga pada akhirnya hanya 80 dan 443 yang lolos. Saya harap IPv6 bisa sedikit memperbaiki keadaan. Dan saya juga berharap dorongan seperti ChatControl di UE dihentikan. Tolong dengarkan orang yang benar-benar paham IT
  • Saya juga mengerti bahwa kompleksitas connection init, yaitu inisialisasi koneksi jaringan, makin tinggi sehingga pada akhirnya kita harus bertumpu pada best practice berbasis protokol yang battle-tested. Tetapi tetap terasa canggung terus menyebutnya http ketika yang ditransfer sebenarnya bukan lagi hypertext
• Evolusi pada fitur SSH sendiri itu keren, tetapi kalau toh pada dasarnya hampir membuat ulang dari nol, saya agak berharap ada fitur baru yang lebih eksperimental juga. Misalnya kemudahan seperti Mosh untuk menghadapi “roaming/ketidakstabilan jaringan sementara” akan sangat bagus https://mosh.org/
  • Kelebihan Mosh adalah respons penekanan tombolnya sangat cepat, rasanya seperti bekerja langsung di shell lokal. Saya penasaran apakah SSH3 juga memperbaiki aspek ini. QUIC mungkin sedikit membantu, tetapi tetap berbeda dari Mosh
  • Sepemahaman saya, dukungan connection migration atau multipath adalah sifat bawaan QUIC, dan soal perbedaan antara fitur roaming dan 'tmux bawaan', saya juga kurang yakin apakah nilai utamanya memang terletak pada integrasi langsung ke sistem
• Saya penasaran dengan orang-orang yang terobsesi pada nama singkat/akronim; menurut saya itu benar-benar tidak bagus. Sekarang nama perintah boleh saja panjang, jadi sebaiknya gunakan nama panjang yang seteknis mungkin dan jelas. Nama lengkap seharusnya jadi default, dan singkatan boleh dipakai oleh sebagian administrator sistem atau distribusi. Yang diajarkan ke orang-orang seharusnya nama lengkapnya. Misalnya Set-Location lebih baik daripada cd, dan nama seperti remote-terminals-over-http3 lebih baik daripada ssh3
• Commit terakhir sudah setahun lalu; adakah yang tahu perkembangan terbaru proyek ini?
• Saya jadi penasaran dengan rencana proyek ini. Baik rilis maupun aktivitas GitHub sudah tidak ada kabar lebih dari setahun. Karena pendekatannya dimulai dari paper, saya pikir mungkin mereka masih melanjutkan riset terkait atau pekerjaan sampingan lain
  • Terima kasih sudah menyoroti poin ini. Secara pribadi saya menganggap proyek ini sudah berakhir. Dengan sekitar 239 commit, ini pada dasarnya masih setingkat Proof of Concept, jadi belum benar-benar layak dipakai secara serius. Sementara itu kubu OpenBSD (OpenSSH) masih sangat aktif, jadi tampaknya masih jauh dari benar-benar bisa tergantikan https://github.com/openbsd/src/commits/master/
• Ide proyeknya bagus. Saya akan sangat tertarik terutama jika bisa diproksikan lewat proxy H3 umum. Ditambah lagi kalau multipath/migration dan isu blocking terkait TCP juga terselesaikan, itu sudah merupakan kemajuan besar