【ITニュース解説】This Is How I Deploy My SSH App

このニュース記事は、SSH（Secure Shell）という技術を使い、まるでWebサイトのようにアプリケーションをインターネットに公開した個人の挑戦について解説している。これは、一般的なWebアプリケーションとは異なるアプローチや、デプロイメント（公開・展開）における具体的な課題と解決策、そしてセキュリティへの配慮を学ぶ良い機会となるだろう。

まず、SSHアプリとは何かを理解する必要がある。普段Webサイトを閲覧するときはHTTP/HTTPSプロトコルを使うWebアプリケーションを利用するが、SSHアプリは、サーバーに安全に接続するためのSSHプロトコルを利用して、文字ベースのインターフェースを持つアプリケーションを動かす。記事の著者は、SSHアプリがWebアプリよりも高速であると考えている。なぜなら、Webアプリのように画像や動画、複雑なJavaScriptなどを読み込む必要がなく、TCPという基本的な通信方法でUnicode文字（世界中の文字を表現できる文字コード）のブロックだけを送受信するからだ。そのため、見た目はReactやVueといったモダンなフレームワークで作られたWebアプリのように華やかではないが、アスキーアートやレトロなターミナル画面が好きな人には魅力的に映る可能性がある。しかし、SSHサーバーを直接インターネットに公開することには、セキュリティ上の不安も伴う、と著者は指摘している。

このSSHアプリを作るために、著者はGo言語の二つのフレームワークを利用した。一つは「Bubbletea」で、これはTUI（Text User Interface、文字ベースのユーザーインターフェース）を作るためのものだ。Webアプリ開発におけるReactやVueのような存在だと考えると分かりやすい。BubbleteaはCharmという企業が開発しており、使いやすく機能も豊富だと評価されている。Elmアーキテクチャという考え方に基づいて作られており、ステート（アプリケーションの状態）管理に工夫が必要だと著者は感じている。もう一つは「Wish」というフレームワークで、これもCharm社製である。WishはSSHアプリの構築に特化しており、Bubbleteaと非常に簡単に連携できる。Webフレームワークを使った経験があれば、ルーティング（どのURLでどの処理をするか）やミドルウェア（リクエストとレスポンスの間に挟まって処理を行う機能）といった概念が共通しているため、学び始めやすいとされている。著者はこれらのライブラリを使って、自身のポートフォリオアプリを作成し、実際に「ssh ssh.hiro.one」というコマンドでアクセスできるように公開している。Webアプリ開発とは異なる部分も多く、特に文字入力欄の扱いには苦労したようだ。

アプリが完成したら、次にインターネットに公開する必要がある。このプロセスをデプロイメントと呼ぶ。著者はまず、自宅にあるRaspberry Pi 4という小型コンピューターでDokployというデプロイツールを動かし、Cloudflare Tunnelというサービスを使って外部に公開しようと考えた。Cloudflare Tunnelは通常、自宅サーバーをインターネットに安全に公開するのに役立つが、問題があった。このサービスはHTTP/HTTPSプロトコルには対応しているものの、SSHが使うTCPプロトコルには完全には対応していなかったのだ。厳密にはブラウザベースのSSH接続はできるが、著者が望むような直接ターミナルから接続する形ではなかった。自宅のインターネットプロバイダがサーバー公開を許可していないという事情もあり、著者は他の安価な方法を探すことになった。

最終的に著者が選んだのは、Google Cloud Platform（GCP）のCompute Engineである。GCPにはe2-microインスタンスという、特定の使用制限内であれば永続的に無料利用できる仮想マシン（VM）のプランがある。ストレージ費用はかかるものの、これが最も費用を抑えられる方法だと判断した。著者の当初の計画は、GCPのVMをSSHのリバースプロキシとして利用し、自宅のサーバーからこのGCPのVMへ「リバースSSH」接続するというものだった。これにより、インターネットからのアクセスはGCPのVMを経由し、そこから自宅のサーバーにあるSSHアプリに到達するという複雑な経路を構築した。

このデプロイ構成には、いくつかの課題が発生した。一つは「レイテンシ（遅延）」の問題である。GCPの無料枠で利用できるCompute Engineのサーバーは、主に米国リージョンに設置されている。著者は東京に住んでいるため、アプリケーションへのリクエストは東京から米国のサーバーへ飛び、そこから自宅の東京のサーバーへ、そしてレスポンスが再び自宅から米国のサーバーを経て東京の著者の元へと戻るという長距離の通信が発生する。この往復の通信経路によって、ページ遷移に0.3秒から4秒程度の遅延が生じることが確認された。趣味のプロジェクトであるため、著者はこの遅延を許容している。

もう一つの課題は「カラー（色表示）」の問題だった。著者のSSHアプリは「catppuccin」というカラーテーマを使っているが、Dockerコンテナ内でアプリを動かす際、デフォルトではTTY（pseudo-TTY、仮想端末）が有効になっていないため、色が正しく表示されず、モノクロになってしまうのだ。Dockerの起動オプションでTTYを有効にすることはできるものの、それでも256色のような豊かな色彩が表現できないという問題に直面した。開発環境では問題なく表示される色が、本番環境では異なるため、著者はこの解決策を模索している。このカラー問題を解決する一つの方法として、アプリをGCPのVMに直接デプロイすることが考えられるが、これはサーバーのセキュリティ脆弱性につながる可能性があり、著者は懸念している。

最後に、著者はこのSSHアプリのセキュリティについて説明している。このアプリはDockerコンテナ内で動作しており、Wishフレームワークで作られたアプリは、OSのシェルに直接アクセスできるSSHサーバーとは異なり、単にSSHプロトコルを使ってリモートクライアントと通信するターミナルアプリである。そのため、仮にアプリが何らかの方法で侵害されたとしても、攻撃者がサーバーのシェルに侵入して悪意のある操作を行うことはできない。さらに、コンテナは隔離されており、「Distroless」という必要最小限の要素しか含まない安全なイメージを使用しているため、シェル（shやbash）自体が存在しない。これにより、万が一の事態に対するセキュリティが強化されている。

このプロジェクトは著者の趣味であり、多少の色の問題や遅延は許容できる範囲だと結論付けている。この記事は、新しい技術の探求、デプロイメントの課題解決、そしてセキュリティへの意識を持つことの重要性を示す良い事例である。