Shell đồ họa native cho SSH

• Nếu máy chủ và thiết bị edge cung cấp shell đồ họa dựa trên trình duyệt thay vì chỉ để lộ terminal, người dùng có thể sử dụng các ứng dụng từ xa trên thiết bị khác một cách tự nhiên hơn
• Shell này cung cấp màn hình chính cho ứng dụng và API tra cứu URL giữa các ứng dụng, tạo ra luồng chuyển tệp hoặc tài nguyên sang ứng dụng phù hợp
• Ứng dụng cung cấp UI bằng một máy chủ HTTP nhỏ, nhưng không phải là máy chủ web công khai thông thường; nó hoạt động như máy chủ riêng, chủ yếu giả định truy cập qua SSH hoặc cục bộ
• Mã hóa không cần từng ứng dụng tự triển khai mà có thể giao cho lớp SSH, nhờ đó mỗi máy chủ ứng dụng giữ được cấu trúc đơn giản với ít phụ thuộc
• Để làm điều này, Lewis đã tạo Outer Loop như một trình duyệt SSH và công bố mã nguồn mở Outer Shell, đồng thời tính đến cả ứng dụng HTML lẫn ứng dụng native outerframe

---

Shell đồ họa chạy trên SSH

• Trình duyệt web là một ví dụ đã thiết lập rất tốt luồng trong đó một thiết bị, máy chủ, cung cấp trải nghiệm cho một thiết bị khác, máy khách
• Nếu áp dụng cùng cách này cho máy chủ và thiết bị edge, ta có thể dùng ứng dụng đồ họa trong môi trường từ xa thay vì các ứng dụng dựa trên terminal
• Shell cung cấp màn hình chính cho các ứng dụng, và mỗi ứng dụng phục vụ giao diện người dùng web bằng một máy chủ HTTP nhỏ
• API của shell cho phép các ứng dụng tìm URL của nhau, tạo kết nối giữa các ứng dụng
  • Ví dụ, nếu một ứng dụng đăng ký chính nó là trình soạn thảo văn bản, ứng dụng khác có thể mở tệp văn bản bằng ứng dụng soạn thảo đó khi người dùng nhấp đúp vào tệp
• Ứng dụng có thể là ứng dụng web dựa trên HTML hiện có, hoặc là ứng dụng native outerframe

Cách triển khai và các dự án đã được công bố

• Máy chủ HTTP của ứng dụng thường hoạt động như một máy chủ riêng mà các thiết bị khác trên mạng không thể truy cập
  • Người dùng dùng nó qua SSH hoặc dùng cục bộ
  • Khác với phần lớn công cụ máy chủ dựa trên web hiện có, nó chủ yếu dùng tệp Unix domain socket thay vì cổng localhost
  • Tệp Unix domain socket giống với cổng, nhưng tồn tại trong hệ thống tệp và có quyền người dùng rõ ràng
• Mỗi máy chủ HTTP không cần tự xử lý mã hóa
  • Việc mã hóa được xử lý ở lớp SSH
  • Nhờ vậy, mỗi máy chủ ứng dụng có thể cực kỳ đơn giản và không cần phụ thuộc
• Outer Loop được tạo ra như một trình duyệt SSH cho loại shell đồ họa này
• Mã nguồn mở Outer Shell đã được công bố
• Tài liệu liên quan được cung cấp theo ba nhánh
  • Outer Loop: cách trình duyệt hoạt động
  • Outer Shell: API Outer Shell và cách thêm ứng dụng
  • Outerframe: cách ứng dụng native hoạt động
• Trong trình duyệt, các tính năng như kết nối Unix socket từng được xem là rất ngách, nhưng khi kết hợp với các tính năng như nhận biết SSH và sudo, chúng mở ra những khả năng kỹ thuật mới
• Các ứng dụng web dạng máy chủ riêng lẻ như Jupyter và Tensorboard đã xuất hiện, nhưng vì mỗi ứng dụng dùng một giao thức bảo mật dùng một lần, vẫn chưa hình thành một cách chung để truyền tải chúng “đúng cách”
• Khi AI có thể hỗ trợ viết mã, việc mỗi ứng dụng có codebase riêng cho từng nền tảng mục tiêu trở nên thực tế hơn; một kiến trúc web tự nhiên được đề xuất là dùng HTML cho việc đọc và các ứng dụng nhẹ, còn dùng ứng dụng native tùy biến theo nền tảng cho ứng dụng phục vụ công việc

[GN⁺]

Ý kiến trên Hacker News

• Khá bực mình khi có nhiều phản ứng hạ thấp ý tưởng này. Có vẻ phần lớn độc giả HN vẫn mắc kẹt trong chủ nghĩa TUI thượng đẳng và không mấy quan tâm đến GUI
  Có hai điểm cốt lõi. TUI không hề vượt trội hơn GUI một cách bản chất, và SSH với tư cách là tầng truyền tải nên hỗ trợ không chỉ việc chuyển tiếp pty, tức tầng hiển thị TUI, mà cả tầng hiển thị GUI nữa
  Thực ra cả hai điều này đã được hiện thực trên UNIX từ 30 năm trước, với giao thức X và giải pháp ssh -X. Nhưng X đã không chiến thắng, và tương lai nơi ta đăng nhập vào máy từ xa bằng ssh -X, chạy gnome-control-center, rồi một cửa sổ cài đặt bật lên để cấu hình máy tính từ xa đã không đến. Nếu nghĩ là được thì cứ tự thử, trải nghiệm rất thảm hại
  Dù vậy, nhu cầu này vẫn luôn tồn tại, và các ứng dụng như Jupyter Notebook bắt đầu được phát triển theo dạng web server. Định dạng tài liệu, hệ thống style và ngôn ngữ script phía client của web, dù có đủ loại nhược điểm, vẫn trở nên đủ ổn để làm tầng hiển thị cho ứng dụng tương tác, và vì vốn dĩ xuất phát từ tài liệu từ xa nên cũng có sẵn tính trong suốt qua mạng
  Nhìn vào các ứng dụng Electron thì có thể thừa nhận rằng stack HTML/CSS/JS đã chiếm vị trí thống trị cả ở ứng dụng desktop, và việc tận dụng nó làm tầng hiển thị cho ứng dụng từ xa qua SSH là điều tự nhiên. Dự án này có vẻ cũng đi theo hướng đó
  Ứng dụng Electron, giống như X, cũng tách display server và client, lần lượt gọi là “renderer process” và “main process”, rồi giao tiếp qua IPC. Về lý thuyết, nếu có phương tiện truyền IPC phù hợp thì cũng có thể chạy main process và renderer process trên hai máy khác nhau, nên điều này có vẻ không khác ý tưởng đó là mấy

  • Cũng đã có Thinlinc, NoMachine, X2Go và nhiều cái khác, tất cả đều dùng SSH làm backend chính. Đây là một ý tưởng khá phổ biến
  • ssh -X hoạt động tốt hay không tùy vào toolkit sử dụng và khoảng cách/độ trễ. Ví dụ Gtk không tốt vì pipeline render của nó
    Khi khoảng cách và độ trễ đủ lớn thì phải nghĩ đến việc người dùng sẽ thấy nó thế nào. Bất kể môi trường gì cũng không thể né được giới hạn vật lý. Bất kỳ công cụ nào hứa hẹn truy cập đồ họa từ xa đều phải được thiết kế với độ trễ trong đầu. Vim hoạt động tốt trong môi trường có độ trễ chủ yếu vì nó gần như xếp lệnh vào hàng đợi để gửi đi
  • Giống như X forwarding, cũng có thể dùng Wayland qua SSH, gọi là waypipe. Vậy nên tương lai đó chưa hẳn đã chết
  • Cá nhân tôi lại mừng vì tương lai bật gnome-control-center trên máy từ xa qua ssh -X để cấu hình server đã không xảy ra. Cấu hình server bằng GUI là một cách làm kinh khủng, cứ để nó ở lại trong thế giới Windows thôi
  • Cũng khá khó chịu khi bình luận đầu tiên lúc nào cũng là kiểu chỉ trích những người bình luận khác và hạ thấp suy nghĩ của họ

• Cái này trông giống một giải pháp đi tìm vấn đề, kiểu đã có rất nhiều trong quá khứ. Câu trích dưới đây có vẻ rất hợp với nỗ lực này
  “Những người không hiểu Unix sẽ bị định mệnh buộc phải tái phát minh ra nó một cách tồi tệ.” ~Henry Spencer

  • Tôi từng tuyển một lập trình viên, đưa cho anh ta laptop Linux rồi bảo cấu hình vài thứ, thế mà vài giờ sau anh ta hỏi có thể tải PuTTY ở đâu. Lúc đó tôi nhận ra mình đã bỏ sót rất lớn trong vòng phỏng vấn
  • Không hẳn vậy. Giờ đây nhiều người hơn dùng Linux, nên các quyết định về trải nghiệm người dùng được đưa ra từ 40 năm trước đang bị chất vấn nhiều hơn
    Hầu như mọi máy dành cho lập trình viên đều có cài SSH server và có thể truy cập được
    Tại sao terminal SSH lại phải trông như đống rác chỉ có chữ từ thập niên 1960? Tại sao TUI phải là thứ tốt nhất để đẩy qua SSH? Tại sao không thể xem phim 4K trong terminal hoặc duyệt web bằng pinch-to-zoom?
  • Có vẻ là một đánh giá hơi khắc nghiệt. Thực tế đúng là có một khoảng trống về tính khả dụng, và dự án này là một nỗ lực chạm vào nó
    Ý tưởng xem thư mục Linux qua SSH bằng các thành phần UI native nghe cũng ổn
    Chỉ là một phần trong đó có vẻ là những vấn đề đã được giải quyết theo cách khác, như mount sshfs
  • Phần “những người không hiểu Unix” mới chính là vấn đề gốc rễ thật sự ở đây
    Nó làm tôi nhớ đến một bài viết cũ về thermostat có thể lập trình. Nó đủ mạnh để cấu hình rất sâu, nhưng lại kinh khủng với đa số mọi người khi sử dụng. Ý chính gần như là “người ta không muốn học hệ thống khó nhằn của bạn, họ muốn có được lợi ích mà hệ thống đó hứa hẹn”. UI tốt phải biết thu hẹp khoảng cách đó
  • Cái này có vẻ gần với Plan 9 hơn là UNIX. Không cần phải tôn thờ UNIX quá mức

• Ý tưởng tách frontend và backend của ứng dụng đồ họa là hay. Nhưng khó mà xem là mới, nên có thể tôi đang bỏ sót điều gì đó
  Có vẻ như họ không biết đến X11Forwarding yes hay html5 web app
  Những thứ như để trình duyệt kết nối vào Unix socket từ lâu đã bị bác bỏ vì quá ngách
  Đó là vì lý do bảo mật nên không được triển khai. Ít nhất là với Unix socket thô; còn nếu giới hạn qua WebSocket hay HTTP trên các cổng khác thì vẫn có thể

  • Nói ngắn gọn về bảo mật, các thảo luận tôi từng thấy trên nhiều diễn đàn Mozilla đại khái là thế này
    Không thể cho phép trình duyệt kết nối tới bất kỳ socket nào. Nhiều socket rõ ràng không muốn nhận kết nối từ trình duyệt, hoặc thậm chí không hề tính đến việc trình duyệt có thể kết nối tới
    Vì vậy phải thêm một dạng allowlist, mà như thế thì lại quá phức tạp đối với một tính năng ngách như thế này
    Nên tôi nghĩ cốt lõi là ở tính ngách
    Nhân tiện, Outer Loop có thêm allowlist: https://outerloop.sh/unix-domain-sockets/

• Tôi đang cố hiểu Outer Shell hoạt động như thế nào ở đây. Trên website, họ nêu động cơ như sau
  Các ứng dụng như Jupyter hay TensorBoard khi chạy trên máy chủ từ xa thường không hiển thị trong trình duyệt web thông thường, vì việc để cả Internet truy cập được các ứng dụng này là cực kỳ nguy hiểm. Thay vào đó, chúng chạy trên cổng cục bộ của máy chủ, và máy tính của tôi không thể truy cập trực tiếp vào đó
  Theo cách truyền thống, để truy cập chúng thì phải mở terminal mới và chạy các lệnh như ssh -L 24601:localhost:8889 [e-mail] &, ssh -L 24602:localhost:6006 [e-mail] &
  Có đúng vậy không? Thông thường người ta chỉ dùng kiểu chuyển tiếp SSH này lúc làm prototype thôi, còn khi triển khai thì sẽ tạo một website như myjupyternotebook.com, rồi thêm xác thực để người khác không thể truy cập, đúng không? Ngay cả HTTP Basic Auth cũng không phải chuyện gì quá lớn
  Nếu muốn công khai qua SSH thay vì HTTP, thì cũng còn những lựa chọn khác như đặt nó sau VPN hoặc tunnel
  Outer Loop rất ngầu, nhưng tôi không hiểu rõ vì sao nó cần thiết. Có lẽ tôi đang bỏ sót điều gì đó, nên mong ai đó giúp tôi hiểu vì sao nó được tạo ra

  • Có vẻ như trong những người dùng máy chủ, SSH, v.v. có những nhóm khá khác nhau
    Tôi gần với các trường hợp như thí nghiệm deep learning, tối ưu kernel GPU, phát triển robot hơn. Robot cũng chỉ là những máy chủ biết di chuyển, và trong các trường hợp đó, tôi đang dùng máy tính từ xa một cách rất rõ ràng
    Với nhóm người này, công cụ này có lẽ sẽ trực quan hơn luồng làm việc được đề xuất. Dù vậy, cũng có thể tôi đang phóng chiếu suy nghĩ của bản thân
    Với tôi, đây giống như một trong những thứ mang tính nền tảng có thể tồn tại. Nó cho cảm giác như một hệ điều hành đồ họa ưu tiên remote
  • Nếu chỉ có một người dùng, chính là bản thân họ, và dịch vụ chỉ được truy cập từ hệ điều hành desktop, thì điều này có vẻ giúp tránh được công sức phải xử lý reverse proxy và chứng chỉ TLS
  • Nếu bạn đang chuyển tiếp rất nhiều cổng qua SSH, cũng có thể cân nhắc để SSH khởi động một proxy SOCKS5
    ssh -D 4711 -q -C -N user@host
    Như vậy localhost:4711 sẽ trở thành proxy SOCKS5 có thể cấu hình trong trình duyệt
    Dĩ nhiên WireGuard VPN vẫn tốt hơn. Trên hết, SSH multiplex trên một kết nối TCP duy nhất, nên nếu mất một gói tin thì toàn bộ lưu lượng chuyển tiếp sẽ bị chặn bởi head-of-line blocking cho đến khi gói đó được truyền lại
  • HTTP Basic Auth không an toàn
  • Trường hợp tôi chủ yếu dùng SSH port forwarding là để cứu hộ khi mạng bị hỏng do lỗi cấu hình nào đó

• Có vẻ tác giả chưa từng nghe về Cockpit
  Những thứ được nói là “không tồn tại” hoặc “mới” đều đã có trong Cockpit hơn 10 năm nay rồi. Điều đó bao gồm kết nối máy chủ web dựa trên socket, tách backend-frontend cho ứng dụng máy chủ, thậm chí cả ý tưởng về console máy chủ có kèm truy cập shell
  Với câu hỏi “Có lạ không khi thứ này vẫn chưa tồn tại?”, tôi sẽ trả lời là không. Vì nó đã tồn tại từ lâu rồi

  • “Hãy tử tế. Đừng châm chọc. Đừng tra hỏi, hãy trò chuyện với sự tò mò. Bỏ mỉa mai đi.”
    Trân trọng,
    cảnh sát hướng dẫn HN :-)
    https://news.ycombinator.com/newsguidelines.html
  • Nếu tôi không nhầm thì Cockpit là web UI và không chạy native code. Đó là một khác biệt quan trọng
  • Tôi cũng chưa từng nghe về Cockpit. Nó là gì vậy?

• Bài viết hay đấy. Tôi sẽ bookmark lại để dùng cho nghiên cứu của mình
  Tính năng “clickity clackity” [0] trong terminal của tôi gắn với máy cục bộ, nên ngay khi đi vào môi trường từ xa thì tính đồ họa biến mất
  Điều này đang dần thay đổi nhờ offline replay [1]. Cách làm là để native GUI và TUI hoạt động cùng nhau, mở ra các tính năng như tua ngược. Nhưng vẫn còn khá xa mới hoàn thiện, và thật tốt khi thấy người khác thử nghiệm nghiêm túc. Terminal là một lĩnh vực bị bỏ mặc khá nhiều
  [0] https://terminal.click
  [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

• Những người đã quen với terminal thường quên mất SSH thù địch đến mức nào với những ai không được học nó từ thời đại học
  Nếu điều này có thể giúp một đội nhỏ quản lý VPS hạ thấp rào cản gia nhập mà không cần tuyển riêng một người phụ trách nền tảng, thì như vậy là thành công. Dù vậy, tôi vẫn tò mò họ xử lý key và jump host như thế nào

• Tuyệt vời. Rõ ràng là đang đi đúng hướng
  Lớp tách biệt giữa frontend và backend nên được cắt ở “đơn vị” nhỏ nhất có thể
  Nhiều người đang mỉa mai ở đây rồi cũng sẽ hiểu nếu họ tự mình “cảm nhận” độ trễ và phần overhead bổ sung. Người ta chưa suy nghĩ đủ kỹ về việc cắt dữ liệu cẩn thận sao cho phù hợp với từng use case riêng
  Hơn nữa, với ứng dụng top trong demo — nơi họ nói là “liên tục thay đổi cấu hình để tạo tải” — theo tôi đáng lẽ nên JIT nhiều phần render hơn ở phía client. Khi đó lượng thông tin qua lại giữa Pi và client có thể giảm xuống chỉ còn delta đã nén của đầu ra ps

• Không nên làm vậy. Có rất nhiều lý do bảo mật lâu đời và hợp lý, cũng như lý do về cách ly control plane của web, để không cấp quyền socket thông thường cho trình duyệt
  Phép so sánh gần nhất về mặt cơ học là lý do xe ATV 3 bánh là một ý tưởng tồi

  • Tôi nghĩ sẽ ổn nếu thỏa các điều kiện sau
    Socket phải bị chặn theo mặc định, và chỉ được mở khi phía máy chủ đã thêm rõ ràng vào allowlist
    Phải có nhận thức sudo thực sự, để không thể chạm tới root socket nếu không có mật khẩu sudo. Tính năng này quan trọng vì nếu không, sẽ tạo ra động lực khiến người ta chạy backend root trên các socket mà người dùng có thể truy cập
    Có thêm chi tiết ở đây: https://outerloop.sh/security/