Relayium CLI でサーバー間転送（デーモン直結）
最終更新: 2026-08-05
両方のマシンが自分のもので、互いのアドレスを知っている場合、SSH は余計な手間であり、ランデブーは純粋なオーバーヘッドです。デーモン直結はまさにこのために作られています。一方のサーバーが待ち受け、もう一方が証明書ピンニング付き TLS 1.3 接続でそこへ直接プッシュします。リレーも SSH もペアリングコードも不要。信頼は公開鍵によるもので、一度設定すれば済みます。
本ガイドではリスナーの起動、そこへのプッシュ、初回接触時に新しいプッシュ側を承認すること、自動化、そしてリスナーを systemd サービスとして実行する方法を扱います。
始める前に
以下はすべて relayium CLI なので、未インストールならまず入れてください。macOS または Linux では、1つのコマンドでビルド済みバイナリが PATH に入ります：
curl -fsSL https://relayium.com/install.sh | sh- 自分でファイルを選びたい、または Windows の場合は、リリースページからバイナリを取得してください——relayium.com/cli にすべてのインストール方法があります（Go があれば go build -o relayium ./cmd/relayium も可）。
- relayium --version でインストールを確認できます。これをしないと以下のコマンドは「command not found」と出るだけです。
リスナーを起動する（受信側）
必要なもの
- 自分で管理する2台のマシン。受信側のアドレスが送信側から到達できることが条件です。ホスト名でも生の IP でも構いません。
- 両端の relayium。デーモン直結はネイティブプロトコルしか話さないので、未インストールを救う tar フォールバックはここにはありません。
- リスナーのポートを送信側に開けること。変更しなければ 9031/TCP で、ホストのファイアウォールとクラウドのセキュリティグループの両方が対象です。
- 初回プッシュのために受信側の端末。承認プロンプトに答えるためです。端末が無い場合は、代わりに送信側を事前承認します（後述）。
受信側のサーバーでは、serve がプッシュを待ち受け、あるディレクトリへ書き込みます。デフォルトでは常駐し続けます。--once を付けると1回の転送だけを受け取って終了します。事前に何かを共有しておく必要はありません。あらかじめコピーしておくフィンガープリントもありません：
プッシュが着地するディレクトリを作ります。
mkdir -p ~/inboxリスナーのポートは送信側にだけ開けます。203.0.113.7 は送信側自身のアドレス——グローバル IP、2台が同じネットワークにいるならプライベート IP——に置き換え、クラウドのセキュリティグループもインターネット全体ではなく同じ送信元だけに絞ってください。
sudo ufw allow from 203.0.113.7 to any port 9031 proto tcp初回プッシュの承認プロンプトに答える人がいるよう、端末でリスナーを起動します。--once を足せば1回受けて終了、--port なら 9031 以外に移せます。
relayium serve --dir ~/inbox
リスナーが動いているときの表示
serve は待ち受けたアドレス、書き込み先ディレクトリ、そしてこのホスト自身のフィンガープリントを表示します。承認済みのピアがまだ無いときは、新しいピアごとに確認する旨も表示します。
relayium serve --dir ~/inbox
no authorized peers yet — you'll be asked to approve each new peer on its first push.
relayium serve: listening on [::]:9031, receiving into /home/you/inbox (fingerprint 5c1d9f04…)- リスナーは接続を1つずつ処理し、ファイルを --dir の下に配置します。
- デフォルトのポートは 9031 です。--port で変更し、ファイアウォールで開放してください。
リスナーへプッシュする（送信側）
送信側のサーバーから、受信側の relayium:// アドレスへプッシュします。最初の接続で受信側のフィンガープリントが固定され、以降の接続はすべてそれを検証します。フィンガープリントが変わった場合は黙って受け入れられるのではなく拒否されます。鍵のすり替えや中間者攻撃はそのまま信頼されるのではなく、検知されます。最初のプッシュでは、受信側が承認するまでの間、送信側は少し待機します（次のステップ）。
送信側のサーバーでプッシュを実行します。ごく最初の接続では、受信側が承認するまでちょうどここで止まります。
relayium push ./build.tar.zst relayium://receiver.example.com受信側でプロンプトに答えます。次の節がそれです。あとはプッシュが自力で完了し、以後のプッシュがここで止まることはありません。
リスナーが 9031 以外にいる場合は、末尾にポートを付けます。
relayium push ./build.tar.zst relayium://receiver.example.com:9040
プッシュが成功したときの表示
初回接触で送信側はリスナーのフィンガープリントを学習してピン留めし、そのまま転送します。受信側はプッシュ元のフィンガープリントを記録し、ファイル数とバイト数を報告します。
# on the SENDER, first contact
learned receiver.example.com:9031 5c1d9f04… (added to known_hosts)
build.tar.zst (48213004 bytes)
# on the RECEIVER
authorized 74318e3b… (added to /home/you/.config/relayium/authorized_fingerprints)
received 1 file(s), 48213004 bytes from 74318e3b…- リレーもフォールバックもありません。リスナーに到達できなければプッシュは失敗します。ファイルのバイト列が他の誰かを経由することは決してありません。
- 他のモードと同じ転送エンジンです。再開可能で、ファイルごとに SHA-256 チェックが行われます。
初回プッシュ時に送信側を承認する（受信側）
新しいマシンが初めて自分のリスナーへプッシュすると、serve は（ターミナルで）その送信元とフィンガープリントを表示し、承認するかどうかを尋ねます。SSH の初回接続時のプロンプトに似ていますが、受信側で行われる点が異なります：
# 受信側で、新しい送信側がプッシュしたとき:
Incoming push from 203.0.113.7:54021
fingerprint: 74318e3b…
Accept and remember this peer? [y/N] y- y と答えると、そのフィンガープリントが authorized_fingerprints に記録されます。以降、同じマシンからのプッシュはすべて確認なしで通過します。
- フィンガープリントはそのマシンの安定したアイデンティティであり（再起動や IP の変更を経ても変わりません）、承認はプッシュ側ごとに一度だけで済みます。
- プッシュ側は、初回接続時にリスナーの鍵を学習し（信頼オンファーストユース）、known_hosts に固定します。
自動化する（またはターミナルなしで実行する）
承認済みのフィンガープリントは記憶されるため、以降のプッシュにはプロンプトが不要になります。そのため relayium push は cron、デプロイスクリプト、CI にそのまま組み込め、暗号化・整合性チェック済み・再開可能なサーバー間同期を実現します。serve がターミナルなしで動作している場合（systemd サービスやパイプなど）はプロンプトを出せないため、未知のプッシュ側を拒否します。その場合は事前に承認してください。フィンガープリントはプッシュ側で relayium id を実行して取得するか、serve のログにある「rejected unauthorized peer …」の行からコピーし、次のように実行します：
# 受信側で: プロンプトなしに送信側を事前承認する
relayium authorize 74318e3b...- アイデンティティと信頼のファイルは ~/.config/relayium/ にあります（サービスとして使う場合など、--config-dir で /etc/relayium などに上書きできます）。
- authorize は冪等です。同じフィンガープリントに対して再度実行しても何も起こりません。
systemd でリスナーを実行する
常時稼働の受信箱にするには、serve を systemd サービスとして実行します。--config-dir を /etc/relayium のような固定の場所に向けて、再起動をまたいでアイデンティティを安定させ、生存は systemd に任せます：
# /etc/systemd/system/relayium-serve.service
[Unit]
Description=Relayium daemon-direct listener
After=network-online.target
[Service]
ExecStart=/usr/local/bin/relayium serve --dir /srv/inbox --config-dir /etc/relayium
Restart=always
User=relayium
[Install]
WantedBy=multi-user.target- systemctl enable --now relayium-serve で起動し、起動時に自動的に立ち上がるようにします。
- /etc/relayium/id.key はサービスユーザーだけが読めるようにしてください。権限が緩い鍵は relayium が読み込みを拒否します。
プッシュが通らないとき
まず見るのは到達性と信頼の2つです。送信側で ss -tinp を実行すればリスナーに届いているかが分かり、受信側の relayium authorize は、拒否された送信側に足りない信頼を与えます。ただしプッシュが失敗する道はこの2種類だけではありません。受信側のディスクが一杯、受信ディレクトリに実行ユーザーが書き込めない、転送されたファイルが整合性チェックに落ちる——どれも自分でエラーを出します。ですから下の4つのどれかだと決めてかからず、目の前のエラーを読んでください。
症状・確認・対処
- プッシュがそのまま止まり、最後に接続エラーで失敗する。
# 送信側で、プッシュ実行中に — 数秒あけて2回実行する ss -tinp dst :9031 # ESTAB リスナーに届いたことだけを示し、進捗までは示さない # SYN-SENT そのポートで誰も応答していないSYN-SENT は、パケットが待ち受け中のソケットまで届いていないという意味です。受信側で ss -tlnp | grep 9031 を実行して serve が起動しているか確かめ、ホストのファイアウォールとクラウドのセキュリティグループで 9031/TCP を送信側に開けてください。ESTAB が示すのは到達できたことだけで、確立済みのソケットが無通信のまま止まっていることもあります。動いているのか止まっているのかを見分けるには、このチェックを数秒あけて2回実行し、-i がそのソケットについて表示する bytes_acked カウンターを比べてください。ここにはリレー経路が無いので、届かないリスナーは遅いのではなく完全な失敗です。
- serve のログに「rejected unauthorized peer …」と出てプッシュが失敗する。
# 送信側で relayium id # 74318e3b… # 受信側で relayium authorize 74318e3b…serve に尋ねる相手の端末が無かった（systemd ユニットやパイプ）ため、未知のフィンガープリントは信頼されずに拒否されます。事前に承認してください。拒否行のフィンガープリントは送信側の relayium id が表示するものとまったく同じで、authorize は何度実行しても同じ結果です。
- 「fingerprint mismatch for receiver.example.com:9031」。
grep receiver.example.com ~/.config/relayium/known_hostsリスナーが、初回接触でピン留めした鍵とは別の鍵を提示しました。意図して鍵を更新したのなら、該当する known_hosts の行を削除してからプッシュし直します。そうでないなら行はそのままにして、鍵が変わった理由が分かるまで何も送らないでください。
- systemd ユニットが起動時にパーミッション不備のエラーで落ちる。
systemctl status relayium-serve # secure: /etc/relayium/id.key has insecure permissions 0644; run: chmod 600 /etc/relayium/id.key ls -l /etc/relayium/id.keyrelayium は所有者以外にも読める秘密鍵の読み込みを拒否します。ssh と同じ規則です。エラーが示すパスに chmod 600 を実行し、所有者がサービス用ユーザーであることを確かめて、ユニットを再起動してください。
よくある質問
デーモン直結は SSH 経由の push と何が違いますか？
SSH 経由の push は転送を SSH 接続のトンネルに通し、リモート側に SSH アカウントが必要です。デーモン直結には SSH もアカウントも不要です。2台のサーバーは証明書ピンニング付き TLS 上で証明書のフィンガープリントによって互いを認証します。両方のマシンが自分のものである場合、これはより軽量です。
フィンガープリントを手作業でコピーして回る必要がありますか？
いいえ。ターミナルでは、serve が新しいプッシュ側の初回プッシュ時にそのアドレスとフィンガープリントを表示し、承認するかどうかを尋ね、それを記憶します。そのため以降のプッシュは確認なしで進みます。relayium id や relayium authorize が必要になるのは、systemd サービスのようにプロンプトに応答する人がいない非対話的な環境を設定する場合だけです。
アイデンティティと信頼のファイルはどこにありますか？
デフォルトでは ~/.config/relayium/ にあります（--config-dir で上書き可能）。id.key / id.crt はこのホストの永続的なアイデンティティ、known_hosts はプッシュ先にしたリスナーのフィンガープリントを保持し、authorized_fingerprints はリスナー側のプッシュ元許可リストです。
フィンガープリントが変わったらどうなりますか？
プッシュは拒否され、警告が出ます。リスナーの鍵は初回使用時に known_hosts に固定されるため、その後の変化（鍵を再生成したホスト、あるいは中間者攻撃）は黙って受け入れられるのではなく拒否されます。known_hosts の該当行を削除するのは、意図的に鍵をローテーションした場合だけにしてください。
リレーへのフォールバックはありますか？
ありません。デーモン直結はリスナーのアドレスに到達できることを前提としています。接続できなければ失敗します。何ものも Relayium を経由してプロキシされることはありません。それがこのモードの要点です。
自分の2台のサーバーをつないで直接転送しましょう。リレーも SSH もペアリングコードも不要です。
CLI を入手する