SSH向けのネイティブなグラフィカルシェル

 (probablymarcus.com)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • サーバーやエッジデバイスがターミナルだけを公開する代わりに、ブラウザベースのグラフィカルシェルを提供すれば、別のデバイスからリモートアプリをより自然に使える
  • このシェルはアプリのホーム画面とアプリ間 URL 参照 APIを提供し、ファイルやリソースを適切なアプリに渡すフローを作れる
  • アプリは小さな HTTP サーバーとして UI を提供するが、一般公開の Web サーバーではなく、主に SSH やローカルアクセスを前提とした非公開サーバーとして動作する
  • 暗号化はアプリごとに直接実装せず SSH レイヤーに任せられるため、各アプリサーバーは依存関係が少なくシンプルな構造を保てる
  • Lewis はそのために Outer Loop を SSH ブラウザーとして作り、オープンソースの Outer Shell を公開した。HTML アプリとネイティブな outerframe アプリの両方を想定している

SSH 上で動作するグラフィカルシェル

  • Web ブラウザーは、1 台のデバイスである サーバー が別のデバイスである クライアント に体験を提供する流れを、すでによく確立した例である
  • 同じ方式をサーバーやエッジデバイスに適用すれば、リモート環境でもターミナルベースのアプリではなくグラフィカルアプリを使える
  • シェルはアプリのホーム画面を提供し、各アプリは小さな HTTP サーバーとして Web ユーザーインターフェースを配信する
  • シェル API はアプリ同士がお互いの URL を見つけられるようにし、アプリ間の接続を作る
    • たとえばアプリが自分をテキストエディターとして登録すれば、別のアプリでテキストファイルをダブルクリックして、そのエディターアプリで開ける
  • アプリは既存の HTML ベースの Web アプリでもよく、ネイティブな outerframe アプリでもよい

実装方式と公開されたプロジェクト

  • アプリの HTTP サーバーは、通常はネットワーク上の他のデバイスからアクセスできない非公開サーバーとして動作する
    • ユーザーはこれを SSH 経由で使うか、ローカルで使用する
    • 既存の Web ベースのサーバーツールの多くと異なり、localhost ポートよりも Unix domain socket ファイルを主に使う
    • Unix domain socket ファイルはポートに似ているが、ファイルシステム上に存在し、明示的なユーザー権限を持つ
  • 各 HTTP サーバーは暗号化を直接処理する必要がない
    • 暗号化は SSH レイヤーで処理される
    • このおかげで各アプリサーバーは依存関係なしに非常にシンプルにできる
  • Outer Loop は、このようなグラフィカルシェルのための SSH ブラウザーとして作られた
  • オープンソースの Outer Shell が公開された
  • 関連ドキュメントは 3 系統で提供されている
  • ブラウザーにおける Unix socket 接続のような機能は非常にニッチなものと見なされてきたが、SSH や sudo の認識といった機能と組み合わせることで、新たな技術的可能性が生まれる
  • Jupyter や Tensorboard のような個別サーバー型 Web アプリは登場してきたが、それぞれが一回限りのセキュリティプロトコルを使っており、これを「正しく」受け渡す共通方式は定着しなかった
  • AI がコード作成を支援できるようになったことで、各アプリが対象プラットフォームごとのコードベースを持つことが現実的になり、読むことや軽量なアプリには HTML を、作業用アプリにはプラットフォームに最適化したネイティブアプリを使う構造が自然な Web アーキテクチャとして提案されている

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsの意見

  • このアイデアを貶める反応が多いのはかなりもどかしい。HN読者の多くは今もなおTUI至上主義に囚われていて、GUIにはあまり関心がないように見える
    核心は2つある。TUIがGUIより本質的に優れているわけではなく、SSHは転送層として、pty転送、つまりTUI表示層だけでなくGUI表示層もサポートすべきだということ
    実際、この2つは30年前のUNIXで既に実現されていて、Xプロトコルとssh -Xという解決策もあった。だがXは勝利せず、リモートマシンにssh -Xで接続してgnome-control-centerを実行すると設定ウィンドウが開き、リモートコンピュータを設定できる、という未来は来なかった。できると思うなら実際にやってみればいいが、体験はひどいものだ
    それでもこの必要性は残り続け、Jupyter NotebookのようなアプリはWebサーバー形式で開発され始めた。Webの文書形式、スタイリング、クライアント側スクリプト言語は、あらゆる欠点にもかかわらず対話型アプリの表示層として使えるものになり、そもそもリモート文書から出発しているためネットワーク透過性も組み込まれている
    Electronアプリを見ると、HTML/CSS/JSスタックがデスクトップアプリでも支配的な地位を占めたことを認め、それをSSH経由のリモートアプリ表示層として活用するのは自然だ。このプロジェクトもそうした流れに見える
    ElectronアプリもXのように表示サーバーとクライアントが分かれており、それぞれ「renderer process」と「main process」と呼ばれ、IPCで通信する。理論上は適切なIPC転送手段さえあれば、main processとrenderer processを別々のマシンで実行することもできるはずで、このアイデアと大きく違わないように見える

    • Thinlinc、NoMachine、X2Goのようなものもあり、いずれも主要なバックエンドとしてSSHを使う。かなり一般的なアイデアだ
    • ssh -Xは、使うツールキットや距離・遅延時間によってはうまく動く。例えばGtkはレンダリングパイプラインのせいで良くない
      距離と遅延時間が十分に大きくなると、ユーザーにどう見せるかを考えなければならない。媒体に関係なく物理的な限界は避けられないからだ。リモートグラフィックアクセスを約束するツールならどれも、遅延時間を念頭に置いて設計すべきだ。vimが遅延時間下でもうまく動くのは、実質的にコマンドをキューに積んで送っているからだ
    • XフォワーディングのようにWaylandをSSH上で使うことができ、waypipeと呼ばれている。だからその未来が死んだわけではない
    • 個人的には、ssh -Xでリモートマシンのgnome-control-centerを立ち上げてサーバーを設定する未来が来なくてよかったと思う。GUIでサーバーを設定するのは忌まわしいやり方で、Windowsの世界にだけ残っていてほしい
    • 最初のコメントがいつも他のコメント投稿者を非難し、その考えを貶める内容なのもかなりうんざりする

  • これは過去にもたくさんあった、問題を探している解決策のように見える。下の引用はこの試みによく合っていると思う
    「Unixを理解しない者は、それを出来の悪い形で再発明する運命にある。」〜Henry Spencer

    • プログラマーを雇い、LinuxノートPCを渡していくつか設定をさせたところ、数時間後にPuTTYをどこで入手できるかと聞いてきた。その時、面接で大きく見落とした部分があったことに気づいた
    • そうではない。今やより多くの人がLinuxを使うようになり、40年前に下されたユーザー体験上の決定が、より多く問い直されるようになったのだ
      ほぼすべての開発者向けマシンにはSSHサーバーがインストールされ、アクセス可能になっている
      なぜSSHターミナルは1960年代式の文字だけのゴミのように見えなければならないのか。なぜTUIがSSHに流す最良の対象でなければならないのか。なぜターミナルで4K映画を見たり、ピンチズームでWebを閲覧したりできないのか
    • 少し厳しすぎる評価に見える。実際にユーザビリティの空白があり、このプロジェクトはそこに触れてみる試みだ
      SSHでLinuxディレクトリをネイティブUIコンポーネントとして見るというアイデアなどは悪くなさそうだ
      ただし一部はsshfsマウントのように、既に別の方法で解決された問題のようにも見える
    • 「Unixを理解しない者」という部分こそ、むしろここでの本当の根本問題だ
      昔読んだプログラマブル・サーモスタットに関する記事を思い出す。非常に深く設定できるほど強力だが、ほとんどの人にとっては使うのがひどくつらい、という内容だった。要点は「人々はあなたの難解なシステムを学びたいのではなく、そのシステムが約束する利益を求めている」に近かった。良いUIはその隔たりを最小化できるべきだ
    • これはUNIXというよりPlan 9に近いように見える。UNIXをあまり崇める必要はない

  • グラフィックアプリのフロントエンドとバックエンドを分離するというアイデアは良い。だが新しいとは言いにくく、何か見落としているのかもしれない
    X11Forwarding yesやhtml5 web appを知らないように見える
    ブラウザがUnixソケットに接続する機能のようなものは、極めてニッチな機能だという理由で却下されてきた
    それはセキュリティ問題なので実装されなかったのだ。少なくとも生のUnixソケットについてはそうで、WebSocketやHTTPに限定された別ポートなら可能だ

    • セキュリティについて短く答えると、複数のMozillaフォーラムで見た議論はおおよそ次のようなものだった
      ブラウザが任意のソケットに接続することを許可するわけにはいかない。多くのソケットは明示的にブラウザ接続を望んでいないか、ブラウザが接続できるという事実自体を意識していないからだ
      そのため何らかの許可リストを追加する必要があり、そうなるとこのようなニッチ機能としては複雑すぎる
      だから核心はニッチ性だったのだと思う
      ちなみにOuter Loopは許可リストを追加している: https://outerloop.sh/unix-domain-sockets/

  • ここで Outer Shell がどう動作するのか理解しようとしているところ。Webサイトでは動機をこう示している
    Jupyter や TensorBoard のようなアプリは、リモートサーバー上で実行されている場合、通常は標準のWebブラウザからは見えない。インターネット全体にこのアプリへのアクセスを許すのは非常に危険だから。代わりにサーバーのローカルポートで実行され、自分のコンピューターからはそこへ直接アクセスできない
    従来はこれにアクセスするために新しいターミナルを開き、ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &、ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com & のようなコマンドを実行する必要があったという
    これは合っているのか？ 普通はプロトタイピング時だけこうしたSSHフォワーディングを使い、デプロイ時には myjupyternotebook.com のようなWebサイトを作って認証を付け、他人がアクセスできないようにするのではないか。HTTP Basic認証もそこまで大ごとではない
    公開する先をHTTPではなくSSHにしたいなら、VPNやトンネルの背後に置くといった別の選択肢もある
    Outer Loop はとてもクールだが、なぜ必要なのかよく分からない。何か見落としている気がするので、なぜ作ったのか理解する手助けをしてほしい

    • サーバーやSSHなどを使う人たちには、互いに異なるクラスターがあるように思う
      私はディープラーニング実験、GPUカーネル最適化、ロボット開発のような用途に近い。ロボットは動くサーバーにすぎず、このような場合は明示的に リモートコンピューター を使っている
      このクラスターの人たちには、提案されたフローよりもこのツールのほうが直感的に感じられると思う。ただ、自分の考えを投影しているだけかもしれない
      私には、これは存在し得る根本的なものの一つのように感じる。リモートファーストなグラフィカルOS のようなものだ
    • ユーザーが1人で、それが自分自身であり、デスクトップOSからだけサービスにアクセスする用途なら、リバースプロキシとTLS証明書 を扱う手間を省いてくれるものに見える
    • SSHで多くのポートをフォワードしているなら、SSHに SOCKS5プロキシ を起動させる選択肢も検討できる
      ssh -D 4711 -q -C -N user@host
      こうすると localhost:4711 がブラウザに指定できるSOCKS5プロキシになる
      もちろん WireGuard VPN のほうが良い。何よりSSHは単一のTCP接続上で多重化するため、パケットが1つ失われると再送されるまで、すべてのフォワーディングトラフィックが止まる ヘッドオブラインブロッキング に見舞われる
    • HTTP Basic認証は安全ではない
    • SSHポートフォワーディングを主に使うのは、何らかの設定ミスでネットワークが壊れたときの救出時だ

  • 著者は Cockpit を聞いたことがないようだ
    「ない」とか「新しい」と言っているものは、10年以上前から Cockpit に入っていた。ソケットベースのWebサーバー接続、サーバーアプリのバックエンドとフロントエンドの分離、シェルアクセスを含むサーバーコンソールという発想まで、すべてそうだ
    「これがまだ存在しないのは変ではないですか？」という質問には、いいえと答える。すでにずっと前から存在していたからだ

    • 「親切にしましょう。皮肉を言わないでください。問い詰めるのではなく、好奇心をもって会話しましょう。嫌味は消しましょう。」
      心を込めて、
      HNガイドライン警察 :-)
      https://news.ycombinator.com/newsguidelines.html
    • 私が間違っていなければ Cockpit は Web UI で、ネイティブコードは実行しない。重要な違いだ
    • Cockpit は私も聞いたことがない。それは何？

  • 素晴らしい記事。自分の研究用にブックマークしておく
    私のターミナルの “clickity clackity” 機能 [0] はローカルマシンに結び付いているので、リモートに入った瞬間にグラフィカルさが失われる
    これはオフライン再生 [1] のおかげで少しずつ変わりつつある。ネイティブGUIとTUIが連携して、巻き戻しのような機能を開く方式だ。ただし道のりはかなり長く、他の人たちがちゃんと実験している様子を見るのは良いことだ。ターミナルは大きく放置された領域 だ
    [0] https://terminal.click
    [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

  • ターミナルに慣れた人たちは、大学で学んでいない人にとって SSHがどれほど敵対的か を忘れている
    これがVPSを管理する小さなチームにとって、プラットフォーム担当者を雇わずに参入障壁を下げられるなら成功だ。ただし、鍵とジャンプホストをどう扱うのかは気になる

  • すごい。確実に正しい方向へ進んでいる
    フロントエンドとバックエンドの間の 分離レイヤー は、可能な限り最小の「断片」で切るべきだ
    ここで皮肉を言っている多くの人も、レイテンシと追加オーバーヘッドを実際に「感じれば」理解するだろう。個別のユースケースに合わせてデータを慎重に切り出すことに、十分な検討がなされていない
    さらに言えば、デモで「設定を頻繁に動かして負荷を作る」としていた top アプリは、クライアント側でレンダリングをもっとJIT処理すべきだったと思う。そうすれば Pi とクライアントの間を行き来する情報は、ps 出力の 圧縮された差分 程度に減ったはずだ

  • これはやるべきではない。ブラウザに汎用ソケット権限を許可しないことには、昔からある優れたセキュリティ上の理由と Web制御プレーンの分離 の理由が非常に多くある
    機械的に最も近い比喩は、三輪ATVが悪いアイデアである理由だ

    • 次の条件なら問題ないと思う
      ソケットはデフォルトでブロックされ、サーバー側で明示的に許可リストへ追加された後にのみ開かれるべきだ
      本物のsudo認識があり、sudoパスワードなしにはrootソケットに到達できないようにすべきだ。この機能が重要なのは、そうでないと、人々がユーザーからアクセス可能なソケットでrootバックエンドを実行するよう誘導されるインセンティブが生まれるからだ
      詳細はこちら: https://outerloop.sh/security/