Shell grafis native untuk SSH

 (probablymarcus.com)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Jika server dan perangkat edge menyediakan shell grafis berbasis browser alih-alih hanya mengekspos terminal, aplikasi jarak jauh dapat digunakan dengan lebih alami dari perangkat lain
  • Shell ini menyediakan layar beranda aplikasi dan API pencarian URL antar-aplikasi, sehingga memungkinkan alur untuk meneruskan file atau resource ke aplikasi yang sesuai
  • Aplikasi menyediakan UI melalui server HTTP kecil, tetapi bukan sebagai server web publik biasa; melainkan berjalan sebagai server privat yang terutama mengasumsikan akses melalui SSH atau akses lokal
  • Enkripsi tidak perlu diimplementasikan langsung oleh setiap aplikasi, melainkan dapat diserahkan ke lapisan SSH, sehingga setiap server aplikasi dapat mempertahankan struktur yang sederhana dengan sedikit dependensi
  • Untuk ini, Lewis membuat Outer Loop sebagai browser SSH dan merilis Outer Shell sebagai open source, dengan mempertimbangkan baik aplikasi HTML maupun aplikasi outerframe native

Shell grafis yang berjalan di atas SSH

  • Web browser sudah menjadi contoh yang memantapkan alur di mana satu perangkat, yaitu server, menyediakan pengalaman ke perangkat lain, yaitu client
  • Jika pendekatan yang sama diterapkan pada server dan perangkat edge, aplikasi grafis dapat digunakan di lingkungan jarak jauh alih-alih aplikasi berbasis terminal
  • Shell menyediakan layar beranda untuk aplikasi, dan setiap aplikasi menyajikan antarmuka pengguna web melalui server HTTP kecil
  • Shell API memungkinkan aplikasi menemukan URL satu sama lain, sehingga menciptakan koneksi antar-aplikasi
    • Misalnya, jika sebuah aplikasi mendaftarkan dirinya sebagai editor teks, aplikasi lain dapat membuka file teks di aplikasi editor tersebut dengan double-click
  • Aplikasi bisa berupa aplikasi web berbasis HTML yang sudah ada, atau aplikasi outerframe native

Cara implementasi dan proyek yang dirilis

  • Server HTTP aplikasi umumnya berjalan sebagai server privat yang tidak dapat diakses dari perangkat lain di jaringan
    • Pengguna memakainya melalui SSH atau secara lokal
    • Berbeda dari sebagian besar tool server berbasis web yang sudah ada, ini terutama menggunakan file Unix domain socket alih-alih port localhost
    • File Unix domain socket mirip dengan port, tetapi berada di filesystem dan memiliki izin pengguna yang eksplisit
  • Setiap server HTTP tidak perlu menangani enkripsi secara langsung
    • Enkripsi ditangani di lapisan SSH
    • Berkat ini, setiap server aplikasi dapat sangat sederhana tanpa dependensi
  • Outer Loop dibuat sebagai browser SSH untuk shell grafis seperti ini
  • Outer Shell open source telah dirilis
  • Dokumentasi terkait disediakan dalam tiga bagian
  • Fitur seperti koneksi Unix socket di browser selama ini diperlakukan sebagai fitur yang sangat niche, tetapi jika digabungkan dengan fitur seperti kesadaran terhadap SSH dan sudo, kemungkinan teknis baru dapat muncul
  • Aplikasi web berbentuk server mandiri seperti Jupyter dan Tensorboard memang telah muncul, tetapi masing-masing menggunakan protokol keamanan sekali pakai, sehingga belum terbentuk cara umum untuk menyampaikannya dengan “benar”
  • Seiring AI mulai dapat membantu penulisan kode, memiliki codebase per platform target untuk setiap aplikasi menjadi praktis; dan arsitektur web yang diusulkan terasa alami: gunakan HTML untuk aplikasi baca dan aplikasi ringan, serta aplikasi native yang disesuaikan dengan platform untuk aplikasi kerja

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Pendapat Hacker News

  • Cukup menjengkelkan melihat banyak reaksi yang meremehkan ide ini. Banyak pembaca HN tampaknya masih terjebak dalam supremasi TUI dan tidak terlalu tertarik pada GUI
    Ada dua hal utama. TUI tidak secara inheren lebih unggul daripada GUI, dan SSH sebagai lapisan transport seharusnya mendukung penerusan pty, yaitu bukan hanya lapisan tampilan TUI, tetapi juga lapisan tampilan GUI
    Sebenarnya dua hal ini sudah terwujud di UNIX 30 tahun lalu, dan sudah ada solusi berupa protokol X serta ssh -X. Namun X tidak menang, dan masa depan ketika kita bisa masuk ke mesin jarak jauh dengan ssh -X, menjalankan gnome-control-center, lalu jendela pengaturan muncul untuk mengonfigurasi komputer jarak jauh tidak pernah datang. Kalau merasa itu bisa dilakukan, coba saja sendiri; pengalamannya menyedihkan
    Meski begitu, kebutuhan seperti ini terus ada, dan aplikasi seperti Jupyter Notebook mulai dikembangkan dalam bentuk server web. Format dokumen, styling, dan bahasa skrip klien milik web, terlepas dari segala kekurangannya, menjadi cukup layak dipakai sebagai lapisan tampilan untuk aplikasi interaktif, dan karena sejak awal berangkat dari dokumen jarak jauh, transparansi jaringan juga sudah tertanam di dalamnya
    Melihat aplikasi Electron, wajar untuk mengakui bahwa stack HTML/CSS/JS sudah menempati posisi dominan bahkan di aplikasi desktop, lalu memanfaatkannya sebagai lapisan tampilan aplikasi jarak jauh melalui SSH. Proyek ini juga tampak mengikuti arus itu
    Aplikasi Electron, seperti X, juga memisahkan server tampilan dan klien, masing-masing disebut “renderer process” dan “main process”, serta berkomunikasi lewat IPC. Secara teori, selama ada sarana transport IPC yang tepat, main process dan renderer process juga bisa dijalankan di mesin yang berbeda, dan itu tampaknya tidak jauh berbeda dari ide ini

    • Ada juga Thinlinc, NoMachine, X2Go, dan semuanya memakai SSH sebagai backend utama. Ini ide yang cukup umum
    • ssh -X bisa bekerja dengan baik tergantung toolkit yang dipakai serta jarak/latensi. Misalnya Gtk kurang bagus karena pipeline rendering-nya
      Ketika jarak dan latensi sudah cukup besar, kita perlu memikirkan bagaimana ini akan terlihat bagi pengguna. Batas fisik tidak bisa dihindari, apa pun medianya. Alat apa pun yang menjanjikan akses grafis jarak jauh harus dirancang dengan mempertimbangkan latensi. vim bisa bekerja baik di tengah latensi pada dasarnya karena ia mengantrekan perintah untuk dikirim
    • Seperti X forwarding, Wayland di atas SSH bisa dipakai, dan itu disebut waypipe. Jadi masa depan itu belum mati
    • Secara pribadi, saya justru bersyukur masa depan untuk menjalankan gnome-control-center di mesin jarak jauh lewat ssh -X demi mengatur server tidak pernah datang. Mengonfigurasi server lewat GUI adalah cara yang menjijikkan, dan semoga tetap tinggal di dunia Windows saja
    • Cukup menyebalkan juga bahwa komentar pertama selalu berisi kecaman terhadap komentator lain dan meremehkan pemikiran mereka

  • Ini terlihat seperti solusi yang sedang mencari masalah, sesuatu yang sudah banyak ada di masa lalu. Kutipan di bawah tampaknya cocok dengan upaya ini
    “Orang yang tidak memahami Unix ditakdirkan untuk menciptakannya kembali dengan buruk.” ~Henry Spencer

    • Pernah mempekerjakan seorang programmer dan memberinya laptop Linux untuk melakukan beberapa pengaturan, lalu beberapa jam kemudian ia bertanya di mana bisa mengunduh PuTTY. Saat itu saya sadar ada hal besar yang terlewat dalam wawancara
    • Tidak begitu. Kini semakin banyak orang memakai Linux, sehingga keputusan pengalaman pengguna yang dibuat 40 tahun lalu semakin banyak dipertanyakan
      Hampir semua mesin untuk developer memiliki server SSH terpasang dan dapat diakses
      Mengapa terminal SSH harus terlihat seperti sampah teks-saja ala 1960-an? Mengapa TUI harus menjadi target terbaik yang dialirkan melalui SSH? Mengapa kita tidak bisa menonton film 4K di terminal atau menjelajah web dengan pinch zoom?
    • Itu terdengar seperti penilaian yang agak keras. Sebenarnya ada kesenjangan usability, dan proyek ini mencoba menyentuhnya
      Ide seperti melihat direktori Linux lewat SSH sebagai komponen UI native tampak cukup bagus
      Namun sebagian tampaknya memang sudah diselesaikan dengan cara lain, seperti mount sshfs
    • Bagian “orang yang tidak memahami Unix” justru merupakan masalah mendasar yang sebenarnya di sini
      Saya teringat tulisan lama tentang termostat yang dapat diprogram. Isinya kira-kira: sangat kuat karena bisa dikonfigurasi sangat dalam, tetapi mengerikan dipakai bagi kebanyakan orang. Intinya dekat dengan “orang tidak ingin mempelajari sistem rumitmu; mereka menginginkan manfaat yang dijanjikan sistem itu.” UI yang baik harus mampu meminimalkan celah itu
    • Ini tampak lebih dekat ke Plan 9 daripada UNIX. Tidak perlu terlalu memuja UNIX

  • Ide memisahkan frontend dan backend aplikasi grafis itu bagus. Namun sulit menyebutnya baru; mungkin saja ada sesuatu yang saya lewatkan
    Sepertinya mereka tidak tahu X11Forwarding yes atau html5 web app
    Fitur seperti browser yang bisa terhubung ke Unix socket selama ini ditolak karena dianggap sangat niche
    Itu tidak diimplementasikan karena masalah keamanan. Setidaknya untuk Unix socket mentah; port lain yang dibatasi ke WebSocket atau HTTP masih memungkinkan

    • Jawaban singkat soal keamanan: diskusi yang saya lihat di beberapa forum Mozilla kira-kira begini
      Browser tidak bisa diizinkan terhubung ke sembarang socket. Banyak socket secara eksplisit tidak menginginkan koneksi browser, atau bahkan tidak menyadari bahwa browser bisa terhubung ke sana
      Jadi harus ditambahkan semacam allowlist, dan itu membuat fitur niche seperti ini menjadi terlalu kompleks
      Jadi menurut saya inti masalahnya memang keniche-an
      Sebagai catatan, Outer Loop menambahkan allowlist: https://outerloop.sh/unix-domain-sockets/

  • Di sini saya sedang mencoba memahami bagaimana Outer Shell bekerja. Di situs webnya, motivasinya dijelaskan seperti ini
    Aplikasi seperti Jupyter atau TensorBoard, jika berjalan di server jarak jauh, biasanya tidak terlihat di browser web standar. Sebab membiarkan seluruh internet mengakses aplikasi ini sangat berbahaya. Sebagai gantinya, aplikasi berjalan di port lokal server, dan komputer saya tidak bisa mengaksesnya secara langsung
    Secara tradisional, untuk mengaksesnya kita harus membuka terminal baru dan menjalankan perintah seperti ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &, ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com &
    Apakah ini benar? Biasanya SSH forwarding seperti ini hanya dipakai saat prototyping, dan saat deployment kita membuat situs web seperti myjupyternotebook.com lalu menambahkan autentikasi agar orang lain tidak bisa mengaksesnya, bukan? HTTP basic auth juga bukan sesuatu yang terlalu sulit
    Jika ingin menjadikan SSH, bukan HTTP, sebagai target yang diekspos publik, ada opsi lain seperti menaruhnya di balik VPN atau tunnel
    Outer Loop sangat keren, tetapi saya tidak begitu paham mengapa ini diperlukan. Sepertinya ada yang saya lewatkan, jadi saya ingin dibantu memahami mengapa ini dibuat

    • Sepertinya ada beberapa kelompok berbeda di antara orang-orang yang memakai server, SSH, dan semacamnya
      Saya lebih dekat dengan penggunaan seperti eksperimen deep learning, optimisasi kernel GPU, dan pengembangan robot. Robot hanyalah server yang bergerak, dan dalam kasus seperti ini kita memang secara eksplisit memakai komputer jarak jauh
      Bagi orang-orang di kelompok ini, alat ini rasanya akan lebih intuitif daripada alur yang Anda usulkan. Meski begitu, mungkin saja saya sedang memproyeksikan pikiran saya sendiri
      Bagi saya, ini terasa seperti salah satu hal fundamental yang memang bisa ada. Rasanya seperti sistem operasi grafis yang mengutamakan remote
    • Jika penggunanya hanya satu orang, yaitu diri sendiri, dan tujuannya hanya mengakses layanan dari sistem operasi desktop, ini tampak seperti cara menghindari kerepotan mengurus reverse proxy dan sertifikat TLS
    • Jika Anda banyak meneruskan port lewat SSH, Anda juga bisa mempertimbangkan opsi membuat SSH memulai proxy SOCKS5
      ssh -D 4711 -q -C -N user@host
      Dengan begitu, localhost:4711 menjadi proxy SOCKS5 yang bisa dikonfigurasi di browser
      Tentu saja WireGuard VPN lebih baik. Terutama karena SSH melakukan multiplexing di atas satu koneksi TCP, sehingga jika satu paket hilang, semua trafik forwarding akan mengalami head-of-line blocking sampai paket itu ditransmisikan ulang
    • HTTP basic auth tidak aman
    • Kasus utama saya memakai SSH port forwarding adalah untuk penyelamatan ketika jaringan rusak akibat salah konfigurasi

  • Sepertinya penulis belum pernah mendengar Cockpit
    Hal-hal yang disebut “tidak ada” atau “baru” itu sudah ada di Cockpit selama lebih dari 10 tahun. Mulai dari koneksi web server berbasis socket, pemisahan backend-frontend untuk aplikasi server, sampai gagasan konsol server yang mencakup akses shell
    Untuk pertanyaan “Aneh bukan kalau ini belum ada?”, jawaban saya: tidak. Karena ini sudah ada sejak lama

    • “Bersikaplah ramah. Jangan menyindir. Jangan menginterogasi, berbicaralah dengan rasa ingin tahu. Hapus sarkasme.”
      Dengan tulus,
      Polisi pedoman HN :-)
      https://news.ycombinator.com/newsguidelines.html
    • Kalau saya tidak salah, Cockpit adalah UI web dan tidak menjalankan kode native. Itu perbedaan penting
    • Saya juga belum pernah mendengar Cockpit. Itu apa?

  • Tulisan yang bagus. Akan saya bookmark untuk riset saya
    Fitur “clickity clackity” di terminal saya [0] melekat pada mesin lokal, jadi begitu masuk ke mesin remote, unsur grafisnya hilang
    Ini perlahan berubah berkat offline replay [1]. Caranya adalah GUI native dan TUI bekerja bersama untuk membuka kemampuan seperti rewind. Namun jalannya masih cukup panjang, dan bagus melihat orang lain bereksperimen dengan serius. Terminal adalah area yang sangat terbengkalai
    [0] https://terminal.click
    [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

  • Orang-orang yang sudah terbiasa dengan terminal lupa betapa tidak ramahnya SSH bagi orang yang tidak mempelajarinya di kampus
    Jika ini bisa menurunkan hambatan masuk bagi tim kecil yang mengelola VPS tanpa perlu merekrut orang khusus platform, maka ini sukses. Namun saya penasaran bagaimana mereka menangani key dan jump host

  • Hebat. Ini jelas bergerak ke arah yang benar
    Lapisan pemisah antara frontend dan backend harus dipotong pada “potongan” sekecil mungkin
    Banyak orang yang menyindir di sini juga akan mengerti kalau mereka langsung “merasakan” latensi dan overhead tambahannya. Belum ada cukup pemikiran untuk memotong data secara hati-hati sesuai tiap use case
    Lebih jauh lagi, menurut saya aplikasi top dalam demo, yang disebut “menggerakkan pengaturan berkali-kali untuk menciptakan beban”, seharusnya melakukan lebih banyak rendering secara JIT di sisi klien. Dengan begitu, informasi yang bolak-balik antara Pi dan klien akan berkurang menjadi kira-kira delta terkompresi dari output ps

  • Jangan lakukan ini. Ada banyak sekali alasan keamanan lama yang kuat serta alasan isolasi control plane web mengapa browser tidak diberi izin socket umum
    Analogi mekanis terdekat adalah mengapa ATV roda tiga adalah ide buruk

    • Menurut saya ini oke kalau syarat berikut terpenuhi
      Socket harus diblokir secara default, dan hanya boleh dibuka setelah secara eksplisit dimasukkan ke allowlist di sisi server
      Harus ada kesadaran sudo yang nyata, sehingga socket root tidak bisa disentuh tanpa kata sandi sudo. Alasan fitur ini penting adalah, jika tidak, orang akan terdorong menjalankan backend root melalui socket yang dapat diakses pengguna
      Detailnya ada di sini: https://outerloop.sh/security/