解决deploy-rs部署时遇到的Nix存储路径签名问题

在使用deploy-rs工具部署NixOS配置到远程服务器时，用户可能会遇到一个常见错误："cannot add path '/nix/store/...' because it lacks a signature by a trusted key"。这个问题通常与Nix的安全机制有关，特别是当系统配置了严格的签名验证时。

问题背景

当尝试通过deploy-rs将构建好的NixOS系统配置推送到远程服务器时，Nix会检查所有传输的存储路径是否由受信任的密钥签名。如果远程Nix守护进程(nix-daemon)配置为要求签名验证，而当前用户未被列为受信任用户，就会导致上述错误。

根本原因

Nix的安全模型设计允许管理员严格控制谁可以向Nix存储中添加内容。默认情况下，只有root用户和wheel组的成员被视为受信任用户。当使用非特权用户通过SSH部署时，如果该用户未被明确列为受信任用户，Nix守护进程会拒绝未经签名的路径。

解决方案

要解决这个问题，需要在目标服务器的Nix配置中添加当前部署用户为受信任用户。具体方法是在NixOS配置中添加以下设置：

nix.settings.trusted-users = ["root" "@wheel" "munnik"];

其中：

• "root"表示root用户
• "@wheel"表示wheel组的所有成员
• "munnik"是具体的部署用户名（根据实际情况替换）

配置详解

1. 信任机制：Nix的信任机制通过trusted-users设置控制，它定义了哪些用户可以向Nix存储中添加内容而无需额外签名验证。

2. 用户与组：配置中可以指定具体用户名或用户组（组名前加@符号）。通常建议同时包含root、wheel组和具体的部署用户。

3. 生效方式：修改此配置后需要重新构建并激活系统配置，通常通过nixos-rebuild switch命令完成。

最佳实践

1. 最小权限原则：只添加必要的用户到受信任列表，避免过度放宽权限。

2. 环境一致性：确保开发环境和生产环境的信任设置一致，避免部署时出现意外。

3. 审计跟踪：对于生产环境，考虑保留签名要求并配置适当的密钥管理，而不是完全禁用签名验证。

4. 多用户协作：在团队环境中，建议使用组管理而不是单独列出每个用户。

替代方案

如果出于安全考虑不能放宽信任设置，也可以考虑以下方法：

1. 配置签名密钥：设置适当的签名密钥并确保部署过程中使用这些密钥签名。

2. 使用特权用户：通过sudo或直接使用root用户进行部署。

3. 本地构建后复制：先在本地构建完整系统，然后使用其他方法（如rsync）复制到目标服务器。

总结

deploy-rs部署过程中遇到的存储路径签名问题通常是由于Nix的安全机制导致的。通过合理配置trusted-users列表，可以在安全性和便利性之间取得平衡。理解Nix的信任模型对于成功部署NixOS系统至关重要，特别是在多用户或自动化部署场景中。