Relayium CLI でサーバー間転送(デーモン直結)

最終更新: 2026-07-08

両方のマシンが自分のもので、互いのアドレスを知っている場合、SSH は余計な手間であり、集合場所を介するのは純粋なオーバーヘッドです。デーモン直結はまさにこのために作られています。一方のサーバーが待ち受け、もう一方が固定された TLS 1.3 接続でそこへ直接プッシュします。リレーも SSH もペアリングコードも不要——信頼は公開鍵によるもので、一度設定すれば済みます。

本ガイドではリスナーの起動、そこへのプッシュ、初回接触時に新しいプッシュ側を承認すること、自動化、そしてリスナーを systemd サービスとして実行する方法を扱います。

リスナーを起動する(受信側)

受信側のサーバーでは、serve がプッシュを待ち受け、あるディレクトリへ書き込みます。デフォルトでは常駐し続けます。--once を付けると1回の転送だけを受け取って終了します。事前に何かを共有しておく必要はありません——あらかじめコピーしておくフィンガープリントもありません:

# on the RECEIVER
relayium serve --dir ~/inbox      # add --once for a single transfer; --port to change 9031

リスナーは接続を1つずつ処理し、ファイルを --dir の下に配置します。
デフォルトのポートは 9031 です。--port で変更し、ファイアウォールで開放してください。

リスナーへプッシュする(送信側)

送信側のサーバーから、受信側の relayium:// アドレスへプッシュします。最初の接続で受信側のフィンガープリントが固定され、以降の接続はすべてそれを検証します。フィンガープリントが変わった場合は黙って受け入れられるのではなく拒否されます——鍵のすり替えや中間者攻撃はそのまま信頼されるのではなく、検知されます。最初のプッシュでは、受信側が承認するまでの間、送信側は少し待機します(次のステップ)。

# on the SENDER
relayium push ./build.tar.zst relayium://receiver.example.com

# non-default port
relayium push ./build.tar.zst relayium://receiver.example.com:9040

リレーもフォールバックもありません。リスナーに到達できなければプッシュは失敗します——ファイルのバイト列が他の誰かを経由することは決してありません。
他のモードと同じ転送エンジンです。再開可能で、ファイルごとに SHA-256 チェックが行われます。

初回プッシュ時に送信側を承認する(受信側)

新しいマシンが初めてあなたのリスナーへプッシュすると、serve は(ターミナルで)その送信元とフィンガープリントを表示し、承認するかどうかを尋ねます——SSH の初回接続時のプロンプトに似ていますが、受信側で行われる点が異なります:

# on the RECEIVER, when a new sender pushes:
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 …」の行からコピーし、次のように実行します:

# on the RECEIVER: pre-authorize a sender without a prompt
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 が読み込みを拒否します。

よくある質問

デーモン直結は 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 を入手する