你的 VPN 密钥任何人都能读取：该修什么

私钥应当只有使用它的服务可读，其他任何人都不能读。修正权限，找到副本，如果文件已暴露就更换密钥。

第一个信号通常只是警告，而不是故障。客户端拒绝加载密钥，因为文件对同组或其他用户可读；或者安全审查发现，在同时存放导出配置的目录里，client.key 的权限仍是 644。还没有出问题，正因如此警告才被忽视。密钥能用，隧道能建立，而机器上的每个账户都能读取这个文件。

症状是权限警告，不是服务中断

在类 Unix 系统上，私钥应当只有运行服务的账户可读。文件名属主正确、权限为 600，是常规做法。权限为 644 意味着每个本地用户都能复制密钥；在共享构建主机上，这确实是真实的读者群。

会检查这一点的客户端是在帮你。不检查的客户端并不能证明文件安全；连接成功也说明不了还有谁能读到促成它的材料。把这条警告当作全部发现。它是准确的，而且它出现在任何人复制文件之前。

让权限与服务身份匹配

仅属主可访问适合由该属主使用的密钥。带有刻意共享组的服务可能需要另一种受控安排，例如对服务账户拥有的密钥开放组读。盲目地把每个文件都设成同一种数字权限会破坏受支持的客户端，而 chmod -R 777 解决不了任何问题。

改动之前先核对属主和服务账户。公共 CA 证书与私有身份密钥即使放在同一目录，保密要求也不同，因此对整个文件夹套用递归权限，等于把两者当成同一个对象。

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

在其他平台上，应使用有文档的密钥库或访问控制模型，而不是把 Unix 权限翻译成猜测。以 private 结尾的文件名只是一个标签，不是强制机制。

找出权限没有覆盖到的副本

编辑器、备份归档、导出的配置文件以及临时打包都可能保留同一份身份。要按内容保护这些副本，因为收紧原文件对归档在上个月 tar 里的那一份毫无作用。

密钥文件上的口令 对存储材料有用，但并不能成为把加密文件连同其密码一起发布的理由。权限保护的是当前文件系统对象；它对已经被复制到别处的凭据没有任何约束。

宣布完成之前先去找副本：grep -rl 在可能的目录里搜密钥的头部行，再看看备份排除项。结果往往比最初那个文件更有意思。

修复之后要验证并轮换

确认目标服务仍能通过认证，再确认没有多余的账户获得访问。诊断输出只保留元数据，因为证明文件可读并不需要把密钥打印出来，而那会把材料写进日志。

如果密钥已经暴露，先收紧权限，然后更换凭据并吊销旧的。POSIX chmod 规范 说明了每个权限位的含义，在下次审查要求你解释所选数字之前，值得先弄清楚。

相关文章