Linux age怎样让多个接收者解密同一份文件

Linux 上用 age 让多个人解密同一份文件，可以在一次加密命令中重复指定 -r 接收者，或重复使用 -R 接收者文件。得到的仍是一份密文，每位接收者只需要自己的私有 identity 就能独立解密，不需要收集其他人的私钥。这是“任意一个获授权接收者可读”，不是“所有人同意后才解锁”。

官方项目地址：https://github.com/FiloSottile/age

一份交付包，两个人独立读取

假设运维人员要把一份经过授权的配置交付给值班人员和审阅人员，两人不同时在线，各自需要读取同一内容。分别加密两份当然能做，但会多出两个交付对象；共享一个口令又会把秘密的分发和更换绑在一起。多接收者适合“内容相同、读取资格并列、私钥分别保管”的情况。

如果两人只能看到不同字段，应先拆分内容，分别制作不同文件；多接收者并不提供文件内部的字段授权。本文只讲原生 age 密钥与文件命令，不引入云平台或密钥托管服务，也没有声称在你的机器上实测。

先分清公开 recipient 和私有 identity

recipient 是发送方用于加密的公开接收者值；identity 是接收方用于解密的私有值。每个人把公开值交给发送方即可，私钥不应随着密文一起发送，也不应为了方便集中放在接收者名单中。公开值虽然不保密，仍须通过可信渠道确认归属：替换成别人的公开值会改变谁能读到文件。

官方 age 手册明确说明多接收者可独立解密。命令形态是重复 -r 或 -R；解密时使用 -d 和 -i。先查看实际安装版本及帮助，不要仅凭发行版名称判断兼容性。

# 两端查看版本与支持选项，避免把其他实现的参数直接套用
age --version
age --help
age-keygen --version

当前官方手册区分经典原生密钥和后量子混合原生密钥，并禁止把两种类型混用于同一个加密文件。以下用不带 -pq 的经典密钥示范基础参数，不代表它提供后量子保障；需要后量子方案时，应让所有参与方确认版本、类型与解密支持，不要仅在其中一人生成密钥时增加一个开关。

选多接收者，还是共享口令

age 的 -p 口令模式不能与其他接收者选项组合使用。不能把它写成“公钥或口令任选”的同一条加密命令。对本例，选择两个人的公开 recipient 即可，不需要把任何私钥送到发送方。

各人生成自己的密钥，再交付公开值

下面这一段由每个接收者分别在自己的机器运行。mktemp 为本次示例创建独立目录，umask 收紧新文件权限；不是要求发送方替所有人生成私钥。

# 每个接收者各自执行；私钥目录不要共享
umask 077
age_key_dir=$(mktemp -d ./age-key-demo.XXXXXX) || exit 1
age-keygen -o "$age_key_dir/identity.txt" || exit 1
# -y只输出对应的公开recipient，不打印私钥正文
age-keygen -y -o "$age_key_dir/recipient.txt" "$age_key_dir/identity.txt" || exit 1
printf '仅交付公开文件：%s\n' "$age_key_dir/recipient.txt"

发送方按已确认的归属，将两个公开文件分别保存为 ./recipients/operator.txt 和 ./recipients/reviewer.txt。这两个文件不是示例私钥，也不是必须使用的文件名。若每个文件只有一个公开 recipient，则一份对应一人；若其中含有多个公开值，它实际上会增加多个读取者。相关生成和 -y 行为见官方 age-keygen 手册。

一次加密，两端分别解密

发送方持有公开文件，以及有权交付的 ./handover.txt。以下使用独立输出目录，避免不小心覆盖以前的交付文件：

# 发送方：公开名单一份对应一人，私钥不参与此命令
umask 077
age_send_dir=$(mktemp -d ./age-send-demo.XXXXXX) || exit 1
if age -e \
  -R ./recipients/operator.txt \
  -R ./recipients/reviewer.txt \
  -o "$age_send_dir/handover.txt.age" ./handover.txt; then
  printf '本次密文：%s\n' "$age_send_dir/handover.txt.age"
else
  printf '加密失败，本次输出不得作为交付成品\n' >&2
  exit 1
fi

-R 文件中一行一个公开接收者，空行与以 # 开头的行会被忽略。人数较多时，可维护一个经过归属确认的 team-recipients.txt，在同一次加密中用一个 -R 读取它。人数少且已经持有公开值时，也可重复 -r；其中的变量必须是完整有效的公开值，不能用省略号代替真实密钥：

# 变量由发送方从已确认的公开recipient取得；此处不填写虚构密钥
# alice_recipient和bob_recipient各表示一个完整公开值
age -e -r "$alice_recipient" -r "$bob_recipient" \
  -o ./handover-new.txt.age ./handover.txt

上面的短写法仅展示参数形态，执行前须设置变量并选用尚不存在的输出路径。age 的 -o 会覆盖已有输出，不能把“文件名不同”当作程序自动保护。

两个人收到同一份 handover.txt.age 后，分别在自己的机器使用自己的 identity。下例假设当前目录中已有收到的密文，以及 ./private/identity.txt 这一私有文件：

# 每个接收者分别运行，-i只指向自己保管的私有identity
umask 077
age_receive_dir=$(mktemp -d ./age-receive-demo.XXXXXX) || exit 1
if age -d -i ./private/identity.txt \
  -o "$age_receive_dir/handover.txt" ./handover.txt.age; then
  printf '解密输出：%s\n' "$age_receive_dir/handover.txt"
else
  printf '解密失败，不要使用本次可能残留的输出\n' >&2
  exit 1
fi

接收方成功后得到同样的明文；一人失败不意味着另一人也需要把私钥交给他。应先确认拿到的是本次密文、使用的是被纳入名单的 identity，并区分权限问题、截断文件和不匹配密钥。不要在工单里粘贴私钥正文排错。

从格式角度看，文件头中的多个接收者条目分别封装同一个文件密钥，文件载荷不是为每个人复制一遍。该结构解释了为何只需一份密文，也解释了为何任一匹配 identity 可以读取；详见age 格式规范。应用命令应交给 age 完成，不要自己手工拼接或改写密文头。

交付前考虑撤销，不能只修改名单

若某人从后续名单移除，新文件应重新按当前名单加密。修改接收者文本文件不会改变已经生成、下载或备份的旧密文；旧接收者若仍保存私钥与旧文件，仍可能解密。重新加密也不能收回他已经取得的明文。需要实时撤销、审计和动态授权的业务，应另外设计受控访问服务，而不是宣称离线加密具备在线权限回收能力。

落地时记录明文版本、公开名单版本、交付对象和密文存放位置，私钥备份则由各接收者按自身保管制度处理。发送方如不把自己的 recipient 纳入名单，不能仅凭自己创建过密文就保证将来能解密。加密也不是发送者签名，不应据此自动认定密文的发送者身份。

多接收者是不是两个人必须同时在场？

不是。每个人独立读取，这是并列授权而非门限方案。如果业务要求双人审批，应在交付或密钥管理层单独实现。

能把私钥文件当接收者名单发给发送方吗？

不应这样做。本例用 -y 提取公开值，发送方拿到公开文件就足以加密；泄露 identity 会暴露对应解密能力。

后来增加一个人，旧文件会自动支持吗？

不会。应在有权访问明文的环境中为新的完整名单生成新密文，并明确交付版本，不要把更新名单与更新密文混为一谈。

对这份两人交付包，最重要的不是增加更多参数，而是保住角色边界：发送方只收公开 recipient，各人只用自己的 identity，密文按当次名单生成，旧文件的读取资格不会靠修改名单自动消失。