为第二台设备新增 Peer 时，最容易担心的不是命令，而是哪一把钥匙应该放在哪一端。WireGuard密钥配置可以从一个原则展开：每个独立设备保管自己的私钥，在 Peer 中登记对方的公钥。
01 / 先分清三种材料
| 字段 | 放在哪里 | 使用边界 |
|---|---|---|
| PrivateKey | 本机 Interface | 保持私密，用于本机身份与密钥协商 |
| PublicKey | 对端 Peer | 由本机私钥推导，交换前核验所属设备 |
| PresharedKey | 同一对 Peer 的两端 | 可选的附加对称密钥，两端必须一致且保密 |
公钥不是网页登录密码，私钥也不能通过重置密码从公钥恢复。公钥可用于识别 Peer，但设备、地址和公钥的对应记录仍应按内部资料管理。预共享密钥不是公钥的替代品；不使用时两端都省略，使用时需通过可信途径同步同一值。配置关系的总览可参考密钥与 Peer 管理指南。
02 / 在各设备本地生成
下面展示的是 Linux 下生成新设备身份的示例，须在受控且没有同名旧文件的目录中执行。umask 077让新文件默认只允许当前用户访问。不要用覆盖旧密钥的方式试错，也不要把命令输出中的秘密粘贴到公开聊天或未知在线解析器。
umask 077
wg genkey > device-private.key
wg pubkey < device-private.key > device-public.key
# 仅在双方决定使用附加预共享密钥时生成
wg genpsk > peer-preshared.key将本机私钥写入本机 Interface，将本机公钥交给对端填写 Peer。服务端自己的公钥则交给客户端。配置文件与密钥备份一样敏感：Linux 下限制目录权限及文件权限，并确认所有者；加密备份应与解密材料分开保存。完整的服务文件管理参见Debian 12 与 wg-quick 服务部署。
03 / 一台设备对应一份身份记录
对每台设备记录非敏感名称、公钥标识、隧道地址、授权网段和负责人。不要让多台同时在线的设备随意共用一对密钥：对端会把它们视为同一身份，Endpoint 随认证流量变化，可能出现互相抢占和难以追踪的访问。服务端登记每台客户端的独立隧道地址，常见 IPv4 主机前缀为 /32。
Peer 公钥正确仍不足以保证地址选择正确。服务端的 AllowedIPs 应描述该客户端允许使用的来源及可经由它到达的网络，而客户端通常填写远端网络。两端不可机械复制；具体解释见AllowedIPs 发送选择与接收检查。普通多客户端部署应避免重复前缀和无意重叠。
04 / 泄露后的轮换要两端协调
- 确认受影响设备与全部相关 Peer，保留管理通道并安排变更窗口。
- 在受控设备生成全新密钥对，通过可信渠道核验新公钥。
- 同步更新对端 Peer 的公钥与原本授权的地址范围；若预共享密钥也泄露，同时协调替换。
- 使运行态和持久化配置一致，确认新身份握手及一次实际业务通信。
- 移除旧 Peer 身份，确认旧配置无法继续接入，再处理不再需要的副本。
只换本机私钥、却不更新对端保存的公钥，会使认证中断。管理员选择重启接口或经过审阅的配置同步方法时，需要理解其对现有连接和路由的影响。不要把原始 showconf或 dump结果当普通日志分享，它们可能包含秘密。
05 / 丢失与公开泄露是两件事
若私钥丢失且没有可用备份，就重新生成身份并更新相关对端，不能从公钥逆推。若密钥曾进入公开仓库，删除最新文件并不消除历史副本，应首先撤销旧身份，再按仓库流程清理历史。备份恢复后也要检查当前授权是否仍适用，而不是把过期 Peer 一并恢复上线。
