離れた場所にあるパソコンを触りたいとき、たいていは何かしらの下準備がいる。ルーターにポート開放の設定を入れるか、どこかのサービスにアカウントを作るか。BitBangという道具は、そのどちらもやらない。実行ファイルを1つ動かすとURLが表示されて、それをブラウザで開くと、もう相手のマシンの端末（コマンドを打つ黒い画面）が目の前にある。
作者はリッチ・ルグラン（Rich LeGrand）氏。8月3日にHackadayが取り上げて広まった。ライセンスはMITで、関連するリポジトリはすべて公開されている。
これまでの遠隔アクセスの面倒さ
作者はプロジェクトの説明で、インターネットの通じ方を2つのルールにまとめている。インターネット上にある機械は、ほかのインターネット上の機械からも、自分の家のネットワーク内の機械からもアクセスできる。一方、家のネットワーク内にある機械は、同じネットワーク内からしかアクセスできない。
後者のせいで、自宅に置いたパソコンやNAS、ラズパイ、カメラのたぐいは、外からは存在しないのと同じ扱いになる。この隙間を埋めるために生まれたのが各種のクラウドサービスで、ファイルならDropbox、開発中のWebアプリならngrok、マシンそのものへのアクセスならTailscale、という住み分けができている。ただしどれも、アカウント登録という入口の手間と、自分のデータが他人のサーバーを通るという性質がついてくる。
SSHでいいのでは、という話もあるが、SSHには外から入ってくるための経路が必要になる。携帯回線やStarlink、あるいは会社や大学のネットワークのように、そもそも自分の一存でポートを開けられない環境は珍しくない。結局そこにVPNなりTailscaleなりを重ねることになり、インストールとアカウントがもう一段増える。加えてSSHは、使う前に有効化と鍵の配置が要る。Raspberry Pi OSでは初期状態で無効になっているし、鍵認証のみの設定なら、まず自分の公開鍵をそのマシンに置く方法を考えるところから始まる。
ブラウザ側で使える三つの機能
BitBangの使い方は、つなぎたい側のマシンでインストーラを走らせて、bitbang serve と打つだけ。root権限もデーモンも設定ファイルもいらず、ふつうのユーザーとして動く。
curl -sSfL bitba.ng/install | sh
bitbang serve実行するとQRコード、URL、6桁のペアリングコードの3つが表示される。URLをブラウザで開いた側が受け取れるものは3種類ある。
1つめが端末。ページの中に本物のターミナルが開き、色もリサイズもコピー＆ペーストも効く。2つめがファイルブラウザで、相手のマシンのファイルを一覧して、中身を確認して、ダウンロードできる。オプションを付ければアップロードも許可できる。
3つめが汎用プロキシで、これがいちばん使い出がありそうな部分だ。ブラウザ側で 192.168.1.10:8080 のようなLAN内のアドレスを打ち込むと、そのWebアプリをあたかも同じネットワークにいるかのように操作できる。ログインもCookieもアップロードもストリーミングもそのまま通る。SSHのポート転送だと、つなぎたいアプリごとに事前にトンネルを決めておく必要があるが、こちらは接続してから行き先を指定する形になっている。
用途を絞りたければ bitbang serve shell や bitbang serve files ~/share のように限定して起動することもできる。接続する側はブラウザでも、同じ実行ファイルの bitbang connect でもよく、bitbang cp でscpのようなファイルコピーもできる。
WebRTCによる直接通信の仕組み
中身を支えているのはWebRTCだ。ZoomやGoogle Meetのビデオ会議を成り立たせている技術で、主要なブラウザにはすでに全部入っている。映像や音声のほかに「データチャネル」という生のデータを運ぶ通り道を持っていて、BitBangはそこにHTTPとWebSocketを流し込んでいる。ブラウザが普通ならTCPソケットで話すところを、WebRTCのデータチャネルで置き換えた、という言い方が近い。
ただしWebRTCは、直接触ろうとするとかなり厄介な代物でもある。シグナリング、SDP、ICE、DTLSのフィンガープリント、TURN——覚えることが多い。作者いわく、その面倒を埋めて隠すのがBitBangの仕事の大半で、利用者が受け取るのはプロトコルではなくアドレス1本、というわけだ。
顔合わせを取り持つのがシグナリングサーバーで、公式には bitba.ng が用意されている。やっているのはブラウザ側のプログラムを配ること、接続してきた機器をRSAで認証すること、そして両者のあいだでICE候補とSDPをやり取りさせること。ここまでで役目は終わり、いったんP2P接続ができてしまえば、その後の通信には一切関わらない。
上の図で真ん中から消えていくのがシグナリングサーバーにあたる。関わらないというより、そもそも中身を見られない設計になっているところがこの仕組みの肝で、種明かしはURLの形にある。
BitBangの機器は初回起動時にRSAの鍵ペアを作り、公開鍵のハッシュが128ビットのIDになる。これがURLの経路部分に入る。そして接続を許可する64ビットのアクセスコードのほうは、URLの # より後ろ——フラグメントに置かれる。ブラウザはフラグメントをサーバーに送信しない仕様なので、bitba.ng は「どの機器につなぎたいのか」は分かっても、「つないでよい資格」は最後まで受け取らない。だから接続の交通整理はできるが、自分から接続を開始することはできない。
通信そのものはWebRTCが暗号化を必須にしている。データチャネルはDTLS 1.2以上、映像はSRTP、シグナリングはHTTPSとWSS。直接の経路がどうしても作れなかった場合にはTURN中継が入るが、中継が運ぶのは暗号文だけだ。それでも他人のサーバーを経由するのが気になるなら、シグナリングサーバー自体がオープンソースなので自分で立てられる。
数字を読み合わせる認証の手順
URLもQRコードも渡せない場面——電話越しとか、部屋の反対側から声で伝えるとか——のために、6桁のペアリングコードが用意されている。ここは単に番号を伝えて終わりではない。
まず bitbang serve 側に5分間有効のコードが表示される。相手はそれを bitba.ng/コード で入力する。すると相手の画面に、今度は別の6桁の数字が出る。それを読み上げてもらい、こちらで打ち込んで承認する、という往復になっている。
この2つ目の数字はSAS（短い認証文字列）と呼ばれるもので、両端がそれぞれ独立に、交渉済みのDTLSフィンガープリントと2つのノンスから計算している。中間に割り込んだ機械はフィンガープリントが必ず違ってしまうので、両者の数字を一致させられない。数字が揃った時点で、あいだに誰もいないことが確認できる、という理屈だ。一度ペアリングすると接続情報が保存されるので、次回からは bitbang connect nas1 のような短い名前で済む。
電話で読み合わせる短いコードで2台を安全に引き合わせるという形は、Magic Wormholeを知っている人には見覚えがあると思う。作者自身も似ていると書いている。
テレプレゼンス・ロボットから生まれた経緯
この仕組みの出発点は2026年ではなく、2010年にさかのぼる。ルグラン氏はカーネギーメロン大学のイラ・ヌルバフシュ氏とGoogle Tech Talkに登壇し、TeRK（Telepresence Robot Kit）という教育用ロボティクスのプロジェクトについて話した。GoogleとIntelが資金を出していた企画だが、そこで出た結論はロボットとあまり関係がなかった。曰く、インターネットは機器にとって壊れている。NATとファイアウォールのせいで、家庭用ルーターの内側にある機器は外から見えない。
当時、GoogleはGoogle Talkの裏で動いていたP2Pエンジンlibjingleをオープンソース化したばかりだった。これを設定不要の機器接続に使いたかったものの、libjingleはXMPPに縛られたC++ライブラリで、ブラウザから使えるものではなかった。手に負える問題ではない、とその時は判断している。
その後の十数年で、つながる機器は「IoT」と呼ばれるようになり、設計はひとつの型に収束した。機器がクラウドと話し、ブラウザも同じクラウドと話し、両者は真ん中で出会う。動きはするが、アカウントとサブスクリプションと、他人のサーバーに置かれた自分のデータがついてくる。その間にlibjingleの直系の子孫であるWebRTCは、静かに全ブラウザへ行き渡っていた。ただしビデオ通話用の技術として広まったので、IoTがクラウド型に固まったあとも、P2Pという選択肢は視野に入らないままだった。
BitBangは、この2つの事実をつないだ結果として作られている。直接のきっかけは、2025年にKickstarterで出た小型テレプレゼンス・ロボット「Goby」。QRコード1つで世界中から到達できる機器を実現するために組んだ通信部分を、約束通りオープンソースにしたのがBitBangというわけだ。
上の図のように、いま公開されているのは1本のURLから端末・ファイル・プロキシが開く形だが、派生プロジェクトも動いている。3Dプリンター管理ソフトOctoPrint用のプラグインは、カメラのH.264映像を含むUI全体を1本のURLで外に出せる。Python向けのライブラリ（pip install bitbang）はFlaskやFastAPIで書いたアプリをそのままURL化する。ロードマップにはシリアルポートの橋渡しや、リモートデスクトップに相当する画面転送も並んでいる。
導入前に押さえておきたい注意点
ここからは、便利さと同じ重さで見ておいたほうがいい部分だ。
まず、URLはそれ自体が鍵として働く。作者もREADMEにはっきり書いているが、URLを持っている人は、そこで公開すると決めたものをそのまま使える。bitbang serve shell で起動していれば、URLを手にした人は端末を手にする。うっかりチャットに貼るとか、スクリーンショットに映り込むといった事故がそのまま被害になる形なので、扱いはパスワードと同じと考えたほうがいい。常設や無人運用のためのPIN指定、毎回使い捨てのIDになるモードも用意されているので、置きっぱなしにするなら併用したい。
Hackadayのコメント欄では、この仕組みが不正アクセス後の遠隔操作（C2）にそのまま転用できるのでは、という指摘が早々に出ていた。ポート開放も管理者権限もアカウントも要らず、通信は暗号化されていて、単一の静的バイナリが持ち込めれば成立する——という特徴は、そのまま裏返せる。導入するなら自分の管理下にある機器にとどめるのが筋で、会社や学校の端末に勝手に入れる話にはしないこと。
成熟度についても正直に見ておきたい。執筆時点の最新版はv0.4.7で、7月31日の公開。1.0にも達しておらず、個人が開発しているソフトウェアで、第三者による監査を受けた製品ではない。v0.4.2のリリースノートには「PINの脆弱性を修正」とあり、まだ荒削りな段階なのは作者も隠していない。試すなら、まずは失っても困らない環境から始めるのが無難だと思う。
対応環境の記述にも少し注意がいる。インストーラはLinuxとmacOSに対応し、アーキテクチャを自動判別してSHA-256のチェックサムまで検証してくれる。Windows向けにはビルド済みの.exeがReleasesに置かれていて、こちらは手動でリネームしてPATHに配置する形。ただし本家リポジトリ側のREADMEには「Linux、ほかは準備中」という古い記述が残っており、2つの説明が食い違っている。動きの速いプロジェクトなので、実際に導入する前にbitbang-cliのREADMEとReleasesで最新の状況を確認してほしい。
なお、この記事は公開されているドキュメントとリポジトリを読んで書いたもので、筆者はまだ手元で動かしていない。使用感については触れていないので、その点は差し引いて読んでもらえればと思う。
コメント