BitBang CLI

BitBang CLI は、単一の静的バイナリで動作するリモートアクセス多機能ツールです。ポートフォワーディングも設定もアカウントも不要で、任意のブラウザから対話型シェルの起動、ファイルの閲覧と転送、リモートマシンのネットワーク上の Web アプリへのアクセスが行えます。

接続したいマシン上で:

curl -sSfL bitba.ng/install | sh
bitbang serve

serve は URL を出力します。任意のブラウザで開くと、ターミナル、ファイルブラウザ、そのマシンのネットワークへのプロキシが利用できます。あるいは、同じバイナリを使って別のターミナルから bitbang connect <url> で接続することもできます。接続はエンドツーエンドで暗号化され、ピアツーピアです。bitba.ng サーバーは両端を引き合わせた後は、介在しません。

bitbang は単一の静的 Go バイナリです。BitBang プロジェクト の一部であり、このホワイトペーパーで設計について詳しく解説しています。

6 桁のコードによるペアリング

URL を貼り付けたり QR コードをスキャンしたりできない場合、たとえば電話中や、声が届く距離にいる場合などは、bitbang serve は短いペアリングコードも出力します。相手は bitba.ng/<code> を開くか、bitbang connect <code> を実行します。すると相手の画面に別の 6 桁の番号が表示されるので、その番号を読み上げてもらいます。それを入力して承認します。中間者は 2 つの番号を一致させることができず、ペアリングによりデバイスの接続資格情報が次回のために保存されます（例: bitbang connect nas1）。Magic Wormhole をご存知なら、形は似ています -- 2 台のマシンを安全に引き合わせる、口頭で伝えるコードです。

なぜ？

• 転送も設定も不要。 NAT、CGNAT、または厳重に制限されたネットワークの背後でも動作します -- ルーターの変更も、VPN も、トンネルデーモンも必要ありません。
• 接続側へのインストール不要。 ブラウザだけで十分です。スクリプト、パイプ、ファイルコピーが必要な場合は CLI もあります。
• 設計上プライベート。 トラフィックは WebRTC/DTLS によるピアツーピアです。シグナリングサーバーがトラフィックを見ることは決してありません。直接経路が不可能な場合でも、TURN リレーが運ぶのは暗号文のみです。
• アカウント不要、テレメトリなし。

なぜ SSH だけではだめなのか？

bitbang は ssh と同じ形をしています。serve、connect、cp はそれぞれ sshd、ssh、scp に対応し、TCP の代わりに WebRTC をトランスポートとして使用します。すでに快適に SSH で接続できるマシンにとって、その違いはあまりメリットになりません。しかし、bitbang の機能のほとんどは、私が頻繁に遭遇する不満から生まれました:

到達性。 リモート SSH アクセスにはインバウンド経路が必要ですが、ほとんどのネットワークではそれを開くかどうかを自分で決められません -- CGNAT（携帯回線、Starlink、多くの ISP）、企業、大学、自治体ネットワークなど。そのため、実際には別のシステムを追加で組み込むことになります。Tailscale、VPN、ngrok -- 追加のインストール、追加のアカウント、常時稼働させる追加のデーモン。bitbang serve は開放ポートを必要とせず、どこからでも動作します。

セットアップ。 SSH は、接続を許可する前に有効化と設定が必要です。Raspberry Pi OS ではデフォルトで無効であり、鍵認証のみの設定が多いため、まず公開鍵をマシンに配置する必要があります。そして、どうやってそれを行うのでしょうか？ 通常、メールか USB メモリが最も手間のかからない方法です。bitbang は代わりに 6 桁のコード交換で接続を確立します -- 電話で安全に行える方法であり、部屋の向こう側に向かって読み上げることもできます。また、通常のユーザーとして実行されるため、root もデーモンも設定ファイルも必要ありません。

プロキシ。 そのマシンのネットワーク上の Web アプリを利用したい場合、SSH ではアプリごとに個別のトンネルを事前に用意する必要があります。bitbang のプロキシは汎用的です。接続時に Web アプリの URL を指定するだけです。

ブラウザクライアント。 SSH では、接続側に SSH クライアントと鍵またはパスワードが必要です。bitbang に必要なのはブラウザだけです -- つまり、スマートフォン、借りたラップトップ、ターミナルを開いたことのない人でも利用できます。URL を渡すだけで、あなたが許可したアクセスが得られます。

bitbang の使い方

すべての接続には 2 つの端点があります。リスナー（接続対象のマシン上で実行される bitbang serve）とコネクター（接続元のマシン上のブラウザまたは bitbang CLI）です。1 つのリスナー URL で両方の種類のコネクターに対応できます。

リスナー: bitbang serve

bitbang serve                    # everything: shell + files + proxy on one URL
bitbang serve shell              # shell only
bitbang serve files ~/share      # files only (add -upload to allow uploads)
bitbang serve proxy              # proxy; pick the target in the browser
bitbang serve proxy localhost:8080   # ...or pin a single target

それぞれ QR コード、URL、ペアリングコードを出力します。

ブラウザからの接続

URL を開きます。提供される内容に応じて、次のものが利用できます:

• シェル -- ページ内の本格的なターミナル（色、リサイズ、コピー/ペースト）。
• ファイル -- 閲覧、プレビュー、ダウンロード、アップロード。
• プロキシ -- LAN アドレス（nas.local、192.168.1.10:8080、localhost:3000/admin）を入力すると、ローカルにいるかのようにアプリを利用できます。ログイン、Cookie、アップロード、ストリーミングもすべて動作します。

CLI からの接続

bitbang connect <url>                                   # interactive shell
bitbang connect <url> -- tail -f /var/log/syslog        # one-shot command
bitbang cp <url>:/var/log/app.log ./app.log             # copy files, scp-style
bitbang cp - <url>:/tmp/firmware.bin < firmware.bin     # stdin/stdout work too

接続またはペアリングが成功するたびに ~/.bitbang/devices.json に保存されるため、以降は短い名前だけで十分です: bitbang connect nas1。

インストール

このワンライナーはアーキテクチャ（amd64、arm64、armv7）を検出し、最新の GitHub リリース からバイナリをダウンロードして、そのリリースの checksums.txt と照合して SHA-256 を検証し、~/.local/bin/bitbang にインストールします。

バージョンを固定する、インストール先を変更する、または事前にスクリプトを監査する場合:

curl -sSfL bitba.ng/install | sh -s -- --version v0.5.0
curl -sSfL bitba.ng/install | sh -s -- --prefix /usr/local/bin

curl -sSfL bitba.ng/install -o install.sh && less install.sh && sh install.sh

macOS と Windows のビルドは準備中です -- それぞれについて issue が作成されています（macOS、windows。興味があればリアクションやコメントでお知らせください。 手動インストール: Releases からバイナリをダウンロードして PATH に配置します。ソースからのビルド: 下記 を参照してください。

インストール URL の仕組み

bitba.ng/install はリダイレクトであり、ホストされたスクリプトではありません。その連鎖は次のとおりです:

1. curl が https://bitba.ng/install にアクセスすると、このリポジトリ（main ブランチ）の install.sh へ 302 リダイレクトされます。
2. スクリプトがシェル内で実行され、OS とアーキテクチャを検出して、https://github.com/richlegrand/bitbang-cli/releases/latest/download/bitbang-linux-<arch> からバイナリアセットをダウンロードします。
3. 同じリリースから checksums.txt を取得し、バイナリの SHA-256 を検証します。
4. ~/.local/bin にインストールします（上書き可能）。

インストールスクリプトは、インストール対象のコードと同じこのリポジトリ内に置かれています -- つまり、バイナリと一緒にレビューでき、公式の bitba.ng ホストが所有するのは短い URL だけです。セルフホストする場合は、自分のホストの /install を配布する任意のスクリプトに向けられます。シグナリングサーバーの INSTALL_URL 環境変数がリダイレクト先を制御します（空 → 404）。

セキュリティ

• 自己証明型アイデンティティ。 初回実行時に、bitbang は ~/.bitbang/<program>/ 配下に RSA 鍵ペアを生成します。デバイス UID は公開鍵から導出されるため、デバイスを偽装するにはその UID の第二原像を見つけ出す必要があります。
• 秘密情報はサーバーに触れません。 アクセスコードは URL フラグメント（#…）に含まれており、ブラウザが送信することはありません。bitba.ng は、接続を許可する資格情報を見ることなく、接続を仲介します。
• エンドツーエンド暗号化。 すべてのトラフィックは WebRTC の DTLS 上を流れます。シグナリングサーバーが見るのは公開鍵、導出された UID、接続メタデータのみであり、データを見ることは決してありません。TURN リレーが必要な場合でも、リレーが見るのは暗号文だけです。
• 検証済みペアリング。 コードペアリングで読み上げる番号は短い認証文字列（SAS）であり、交渉済みの DTLS フィンガープリントと 2 つのコミット済みノンスから両端で独立に計算されます。フィンガープリントが必ず異なる中間者は、2 つの番号を一致させることができません。
• 恒久的またはヘッドレスなセットアップ向けのオプションの PIN（--pin）、および実行ごとに新しいアイデンティティを提供する使い捨てモード（-ephemeral）。

シグナリングサーバーを信頼せずに両端が相互認証する仕組みの詳細は、こちらで解説しています: Trustless Signaling: Authentication Without a Central Authority。

比較

コマンドリファレンス

フラグはどちらの形式（-pin または --pin）でも指定できます。ブールフラグは、特に記載がない限りデフォルトでオフです。

bitbang serve [flags]                  All capabilities: shell + files + proxy on one URL
bitbang serve shell [flags]            Shell only
bitbang serve files [PATH] [flags]     Files only (PATH defaults to cwd)
bitbang serve proxy [TARGET] [flags]   HTTP/WebSocket reverse proxy (TARGET pins one host:port)
bitbang connect <target> [-- cmd …]    Client shell (interactive or one-shot)
bitbang cp <src> <dst>                 Copy files (one side is <URL>:/path, or '-')
bitbang version                        Print version (also --version)
bitbang help                           Usage (also --help, -h)

bitbang serve -- リスナーを実行

共通フラグ（4 つの serve 形式すべて）:

シェルフラグ（serve および serve shell）:

ファイルフラグ:

(上級者向け: -video-fd N は継承した socketpair FD を外部ビデオヘルパーに渡します。内部/組み込み用です。)

bitbang connect <target> [-- command …] -- クライアントシェル

<target> には次のいずれかを指定できます:

• 保存済みの名前 -- 例: nas1。known-hosts テーブルから解決されます（下記参照）
• 6 桁のペアコード -- 例: 482731。ペアリングフローを実行してから接続します
• URL -- https://bitba.ng/<id>#<code>、bitba.ng/<id>#<code>、または <id>#<code> のみ

-- command を指定しない場合は、対話型シェルを開きます（stdin がターミナルの場合は PTY）。-- command args… を指定した場合は、その単一のコマンドを非対話的に実行し、そのステータスで終了します（シグナルによる終了は 128 で報告されます）。

bitbang cp <src> <dst> -- ファイルをコピー

<src> / <dst> のうち正確に一方がリモートで、<URL>:/path の形式で指定します（URL は connect が受け付ける任意の形式）。- は stdin/stdout を意味し、cp <URL>:/f - は stdout にストリーミングし、cp - <URL>:/f は stdin からアップロードします。ローカル側の末尾の / または . は、リモートのベース名を維持します（scp スタイル）。

デバイス名と known-hosts テーブル

接続またはペアリングが成功するたびに ~/.bitbang/devices.json（モード 0600）に記憶されるため、URL やコードの代わりに短い名前で再接続できます:

bitbang connect 482731 -name nas1     # pair once, save it as "nas1"
bitbang connect nas1                  # thereafter, just the name

• -name NAME は名前を選択します。これは新しいホストにのみ適用されます。省略すると、自動名（device1、device2、…）が割り当てられて表示されます（Saved as "device1".）。
• 命名規則: 名前は英字で始まり、英字、数字、-、_ のみを含む必要があります。これにより、6 桁のコードや URL と誤認されることは決してありません。検索と一意性の判定は大文字と小文字を区別しません。
• connect による名前変更は不可: bitbang connect nas1 -name nas2 は拒否されます -- -name は初回保存時のみ使用できます。
• 保存されるタイミング: ペアリングは SAS が検証されるとすぐに記録されます（不安定な再接続でも失われません）。URL 接続は接続完了時に記録されます。
• 各エントリには {name, uid, access_code, server, paired_at} が保存されます。既知のホストに（名前または URL で）再接続すると、その場で情報が更新され、名前が維持されます。

ソースからのビルド

Go 1.25+ が必要です。Pure Go で静的リンク（CGO_ENABLED=0）のため、クロスコンパイルも簡単で、ランタイム依存関係はありません。

go build ./cmd/bitbang/

# cross-compile:
GOOS=linux   GOARCH=arm64        go build -o bitbang-arm64 ./cmd/bitbang/
GOOS=linux   GOARCH=arm GOARM=7  go build -o bitbang-armv7 ./cmd/bitbang/
GOOS=windows GOARCH=amd64        go build -o bitbang.exe   ./cmd/bitbang/
GOOS=darwin  GOARCH=arm64        go build -o bitbang-macos ./cmd/bitbang/

図

ロードマップ

現在提供中: シェル、ファイル、プロキシ。ブラウザまたは CLI から利用でき、さらに scp スタイルのファイルコピーと、保存済みデバイステーブルによるアドホックペアリングも備えています。設計済みで実装予定の機能:

• シリアルブリッジ -- ローカルの仮想ポートからリモートの /dev/ttyUSB0 を操作します（例: Arduino IDE をインターネット経由で実行）。こちら に issue が開かれています。
• TCP ポートフォワーディング -- -L 5432:db.internal:5432 で LAN 内のみのサービスに到達します。こちら に issue が開かれています。
• リモートデスクトップ -- WebRTC ビデオトラック経由の画面表示、データチャネル経由のキーボード/マウス操作。

ライセンス

MIT -- LICENSE を参照してください。

コントリビューション

Issue と PR を歓迎します。