如何安全地与团队共享 SSH 密钥和证书

"把 SSH 密钥用 Slack 发我一下。"每个开发团队都听过这句话。服务器访问很急，新成员要配置开发环境，几分钟后就要部署，偏偏有人没有密钥。

但就是这样一个请求，可能成为一场严重安全事故的开端。

为什么共享 SSH 密钥格外危险

SSH 密钥和普通密码不一样。它授予的是服务器的完整访问权限。

比较项	密码	SSH 密钥
权限范围	特定账户	整台服务器
泄露后的影响	仅该账户	服务器上的全部数据
更换难度	可立即修改	重新生成密钥并更新所有服务器
双因素认证	支持	密钥本身就是认证凭据

SSH 密钥一旦泄露，服务器上的每个文件、每个数据库、每一行代码都会暴露。这与单个密码泄露有本质区别。

团队什么时候需要共享 SSH 密钥

现实中，共享确实有正当理由。

• 共享服务器访问：整个团队都要用的预发布或生产服务器
• 部署密钥：CI/CD 流水线中使用的密钥
• SSL 证书：负责人变更时的证书续期
• API 密钥：第三方集成的认证凭据
• 数据库凭据：紧急故障响应

危险的共享方式

1. Slack 或 Discord 私信

这两个服务都不使用端到端加密，聊天记录默认会在服务器上长期保存。对话中的任何人搜索"ssh"或"key"就能翻出以前共享过的密钥。员工离职时账户可以停用，但他们收发过的密钥仍留在工作区的历史记录中。

2. 邮件

邮件会永久存档在邮件服务器上，一旦被转发就无法控制。只要一台邮件服务器被攻破，所有发送过的密钥都会暴露。

3. 共享的 Google Drive 或 Notion

很难做细粒度的权限控制。文件同步后，本地设备上会留下副本。有人离开团队时，想收回所有副本几乎不可能。

4. 提交到 Git 仓库

这是最危险的方式。密钥会永远留在 Git 历史里，即使删掉文件，也能从历史中恢复。如果仓库是公开的，密钥就等于向全世界公开。

安全的共享方式

方式 1：LOCK.PUB 秘密备忘录（最适合一次性传递）

只需要传递一次密钥时，这是最实用的办法。

1. 在 LOCK.PUB 创建秘密备忘录
2. 粘贴 SSH 密钥或证书内容
3. 设置强密码
4. 把有效期设得尽可能短（1-4 小时，Pro）
5. 链接通过 Slack 发送，密码通过电话告知
6. 接收者把密钥保存到本地后，链接到期失效

优势：

• 密钥不会以明文形式保存在任何持久化服务器上
• 到期后就无法再打开
• 聊天记录里不会留下密钥明文

方式 2：密钥管理工具（适合较大的团队）

使用 HashiCorp Vault、AWS Secrets Manager 或 Google Secret Manager 等专业工具。

• 自带访问控制和审计日志
• 可以自动轮换密钥
• 缺点是成本较高、配置复杂

方式 3：SSH 证书颁发机构（长期方案）

不再共享密钥，而是运行一个 SSH CA，为每个用户签发独立的证书。

• 彻底消除共享密钥的需要
• 可按用户管理访问权限
• 初期搭建成本较高

方式 4：每人一把密钥（最推荐）

条件允许时，为每个人单独签发密钥，而不是全团队共用一把。

原则：共享密钥 < 个人密钥
共享密钥泄露 → 整个团队受影响
个人密钥泄露 → 只影响该用户

不得不共享时的检查清单

如果无法做到每人一把密钥、只能共享，请按下面的清单操作。

传递前

• 密钥的权限范围是否已经设为最小？
• 只读密钥是否就够用？
• 能否加上 IP 限制？

传递中

• 密钥和密码是否通过不同渠道发送？
• 有效期是否设得尽可能短？
• 接收者确认后，发送方能否删除原件？

传递后

• 确认接收者已安全保存密钥
• 确认共享的链接或备忘录已经到期
• 监控密钥的使用日志

密钥轮换周期

定期轮换密钥，可以缩短任何一把泄露密钥的有效窗口。

密钥类型	建议轮换周期
生产服务器密钥	90 天
部署密钥	90 天
SSL 证书	每次续期时
API 密钥	90 天
开发/预发布环境密钥	180 天

DevOps 团队安全检查清单

• 所有服务器是否都使用个人 SSH 密钥？
• 如果存在共享密钥，是否配置了 IP 限制？
• 离职员工的密钥是否会立即停用？
• 是否制定了密钥轮换计划？
• 是否曾把 SSH 密钥提交到 Git 仓库？
• 聊天记录中是否有以明文保存的密钥？
• 传递机密信息时是否使用会到期的渠道？

总结

SSH 密钥和证书是服务器安全的支柱。通过 Slack 私信或邮件发送它们，就像把家门钥匙钉在公共布告栏上。能签发个人密钥就签发个人密钥；实在需要共享时，请使用有效期尽可能短的秘密备忘录。

现在就创建一个秘密备忘录，安全地传递 SSH 密钥。

创建秘密备忘录