在本地生成 WireGuard 密钥对：命令与注意事项

两条命令就能生成一对 WireGuard 密钥，而且两者都随标准工具提供，所以这项任务不需要任何替你生成密钥的网站。出问题的从来不是曲线运算，而是权限位、文件的落点，以及随后发往对端的内容。下面的流程从空目录开始，到一个承载流量的对端结束。执行前先读一遍，因为第一行只有在下一行于同一个 shell 中运行时才有意义。

在同一个 shell 中生成密钥对

文档中的流程要求：在私钥存在之前先限制文件创建，再由它推导出公钥。三行必须放在同一个 shell 会话里：

umask 077  # applies to files created next, so keep the next line in this shell
wg genkey | tee privatekey | wg pubkey > publickey
wg pubkey < privatekey  # re-derive and compare with publickey

wg genkey 会以 base64 写出一个 32 字节的 Curve25519 私钥；wg pubkey 读取它并推导出对应的公钥，而 tee 在把私钥顺着管道往下传的同时把它保存下来。正是这个顺序解释了为什么权限那一行要放在最前面，也解释了为什么把管道粘贴到第二个终端会悄悄丢掉它。文件名只是示例，关键在于两个文件都落在拥有该设备的控制范围内。如果私钥文件已经以默认权限存在，chmod 600 privatekey 只会修正当前文件，对更早产生的副本不起作用。

把私钥那一半留在一台设备上

私钥属于将拥有该身份的那台机器，应放在它保护、且其备份视作凭据的目录里。它不该出现在共享文件夹、发给自己的消息，或附在支持工单里的片段中；而一旦被内嵌复制，配置文件就和密钥一样敏感。一个曾在三个地方出现过的密钥，事后就无法再推敲，这正是把它留在原处的现实理由。

有意销毁退役的文件，是同一习惯的一部分。把它留在下载文件夹里等人发现，则不是。

对端运维需要你提供什么

对端只需要公钥内容以及其运维选定的地址安排，别的都不需要。把这段公钥字符串通过运维期望的渠道发过去，然后在任何人测试之前确认它挂到了哪一条对端条目上，因为正确密钥放错段落时，失败的样子很像密钥本身有问题。要以不折行的一整行发送，因为被拆成两行的密钥会毫无怨言地粘进配置文件，然后再也对不上。

生成密钥本身不授权任何东西。必须在对端配置为接受它，而配置这一步属于管理那一端的人。

用一次真实交换来验证这对密钥

一对密钥只标识隧道的一端；它不会创建路由、解析器条目、转发规则或防火墙放行。对端就绪之后，要验证的是交换而不是文件：wg show 里出现的握手、隧道内会应答的地址，以及一个依赖该路由的应用请求。这三样能把错误的密钥、正确的密钥与缺失的路径区分开。

在部署允许时，每台设备各自保留一个身份，这样丢失的单台设备可以单独吊销，而不必逼所有人重新生成密钥。也正是这个决定，让下面这套替换流程可以安全执行。

无间隙地替换密钥

在设备上生成替代密钥，把新的公钥作为额外对端加入，确认它能承载流量，然后才移除旧的。按这个顺序做，意味着隧道从不会有缺少有效身份的瞬间，而回滚不过是删掉刚刚添加的那条记录。

保留被替换的私钥文件，直到新对端确认无误，然后再有意销毁它。WireGuard 快速入门是这些命令本身的参考，篇幅短到可以在动手前完整读一遍。