在命令行接收文件

最近更新: 2026-08-06

发送只是故事的一半——迟早你也会是接收方：同事想跨网络给你一个文件，你自己的一台机器想把东西交给另一台，或者你想主动从你管理的服务器上取点东西回来。Relayium CLI 用三个不同的命令覆盖这三种情形，而且都不需要账号。

对方用配对码推给你时用 receive；想要一个常驻收件箱、让受信任的机器随时可以推送过来时用 serve；而你主动去连接一台已能 SSH 登录的服务器取文件时用 pull。

三种接收方式，各自适用于什么场景

用哪个命令，取决于谁在发起传输，以及两台机器是怎么互相认识的：

• relayium receive <code> [destdir] ——对方跨网络发给你：他的 CLI 先生成一个配对码，再线下转告你。直接点对点，并给出一段可供核对的 SAS 码。
• relayium serve [--dir D] [--port N] [--once] [--allow-delete] ——这台机器监听 daemon 直连的 relayium:// 推送，默认端口 9031。
• relayium pull [user@]host:src <dest> ——你主动通过 SSH 连接到一台你已能登录的服务器，把文件取回来。

receive：对方跨网络把文件发给你

这是 relayium send 的接收端。对方在自己那边运行 relayium send <path>（事先 relayium login 过），CLI 会生成一个 6 位数字、5 分钟内有效的码并打印出来。然后对方通过你们都信任的渠道告诉你——打个电话、发条消息。你则用这个码运行 receive：

relayium receive 483920

# 或者放进指定的目录
relayium receive 483920 ./downloads

1. 和发送方约好他什么时候执行 send。配对码是从生成那一刻开始计时的，不是从你拿到它的那一刻。

2. 通过你们都信任的渠道拿到这六位数字——一通电话、一个聊天窗口，或者你们同处的那个房间。

3. 在希望文件落地的目录里执行 receive，或者显式指定一个目录。

   relayium receive 483920

   relayium receive 483920 ./downloads

4. 当两个终端都打印出验证码时，把你这边的念出来，确认和对方一致。它不是配对码，而且它是唯一能排除对端被替换的东西。

5. 在终端回到提示符之前不要动它。这是一次实时会话：任何一端关掉，传输就停了。

$ relayium receive 483920
verification code (SAS): 271044 — not the pairing code; compare it on both ends to rule out a substituted endpoint
path: direct

• 连接是直接点对点、端到端加密的；一旦连上，两边的终端会打印出同一个 SAS（简短认证串）。通过带外方式与发送方核对，可以确认固定的 TLS 证书指纹没有被替换、会合服务没有冒充任一端。SAS 认证的是端点，并不证明网络路径上的每一跳。
• 不指定目标目录时，文件会落到当前目录。
• 和 send 一样只走直连：如果两个网络之间找不到直连路径，传输会失败，而不会经中继转发。
• 这是 CLI 自己的配对码协议——CLI 的码只能和 CLI 配对。目前和 relayium.com 浏览器端的配对码或二维码流程互不通用；未来也许会支持，但现在还不能指望。如果你手上只有浏览器，请让发送方改用 relayium up 给你一个下载链接。
• 接收方无论在哪个网络上，都不需要账号。只有发送方需要登录，好让发送端的 CLI 生成配对码。

serve：把这台机器变成一个监听收件箱

serve 的方向正相反：不是你去连别人，而是其他机器通过 relayium:// 直接推送给你——专为你已经信任的机器设计，比如你自己的笔记本推给一台 NAS，或者构建服务器把产物投递到你的机器上——走的是证书固定的 TLS 1.3 连接，无需 SSH，无需会合。

relayium serve

# 指定目录和端口，并允许删除请求
relayium serve --dir ~/incoming --port 9031 --allow-delete

1. 启动监听器，并指定推送文件落地的目录。

   relayium serve --dir ~/incoming

2. 有新机器第一次推送时，serve 会显示它的地址和指纹并询问你。批准一次之后，来自该指纹的推送就会静默通过。

3. 如果这个监听器将来没有终端运行，就不要指望那个提示——没人能回答它，陌生的推送方会被直接拒绝。改用下一节讲的预先授权。

• 新机器第一次向你推送时，serve（在终端中运行时）会显示它的地址和指纹，并请你批准一次；之后同一指纹的推送会静默通过。
• 没有终端时——比如作为 systemd 服务、无 TTY 的脚本——没有人来回应提示，未知推送方会被直接拒绝。这种情况下应改为预先授权，用推送方通过 relayium id 打印出的指纹：

为无人值守的 serve 预先授权

对于无人值守运行的 serve（systemd、后台脚本），让推送方运行 relayium id 打印出它的指纹，然后在接收方这边提前批准它：

relayium authorize <fingerprint>

• --dir 设置文件落地的位置（默认为当前目录）；--once 只接受一次传输就退出；--allow-delete 允许推送方的 --delete（镜像）请求真正在这里删除文件，默认关闭。
• --config-dir（默认 ~/.config/relayium）指向一个位置：这台主机的身份和已授权指纹列表都存放在那里——如果把 serve 作为专用服务运行，可以覆盖它。

pull：主动从你能 SSH 登录的服务器取文件

pull 是 push 的镜像：不是等别人发东西给你，而是你通过已有的 SSH 权限主动连过去，把文件取回来。

relayium pull user@host:/path/to/files ./local-dest

1. 先确认远端真的装了 CLI。pull 是在远端执行 relayium 的，而且不像 push 那样有 tar 兜底，二进制缺失会让整条命令失败。

   ssh user@host command -v relayium

2. 如果没有，先在远端装上。

   curl -fsSL https://relayium.com/install.sh | sh

3. 用你已有的 SSH 访问把文件拉回来。-i 和 -p 的行为与 ssh 自身一致。

   relayium pull user@host:/path/to/files ./local-dest

• 和 push 不同，pull 始终需要远程已经装有 relayium——从裸机服务器 pull 没有 tar 兜底方案。如果远程还没装，先在那边用 curl -fsSL https://relayium.com/install.sh | sh 安装。
• 文件会用逐文件 SHA-256 校验，中断后会自动续传（加 --no-resume 可以禁用）。
• -i 和 -p 的行为和 ssh 自己的 -i/-p 一样，用于指定身份文件或端口。

出问题时怎么办

几乎所有失败的接收都逃不出这五种。你当时跑的是哪条命令，决定了适用哪一条；每一条都有一行可读的输出或一条可跑的命令来判定。

常见问题

接收文件需要账号吗？

不需要。三种方式——receive、serve、pull——都完全免费，你这一端不需要 Relayium 账号。整个过程里唯一需要登录的，是 receive 模式下的发送方，好让发送端的 CLI 生成配对码。

relayium receive 和浏览器的配对码互通吗？

不互通。CLI 的配对码协议和 relayium.com 浏览器端的加入链接、二维码流程是分开的——它们的握手方式不同，目前也无法互相通信，所以 CLI 的码只能和另一个 CLI 配对。这是路线图上的事，现在还不能指望。在此之前，用浏览器接收的人需要的是一个 relayium up 链接，而不是配对码。

如果一台未知机器向我的 serve 监听端推送会怎样？

在终端中，会在它首次推送时提示你按地址和指纹批准，批准结果会被记住。没有终端时——比如作为 systemd 服务或 cron 任务——没有人来回应，未知推送方会被拒绝；应先用 relayium authorize <fingerprint> 预先授权。

能从一台没装 relayium 的服务器 pull 吗？

不能。pull 始终需要远程装有 relayium；不像 push 那样有 tar 兜底方案。请先在远程安装 relayium。

relayium 把我的身份和受信任的对端存在哪里？

默认在 ~/.config/relayium 中——在任何涉及身份或信任的命令上，都可以用 --config-dir 覆盖这个位置。

继续阅读

• 用 Relayium CLI 跨网络把文件发给对方
• 把 Relayium 变成常驻接收服务
• 用 Relayium CLI 从终端传输文件与文本
• Relayium 对比 croc：从终端加密传输文件
• Relayium