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

"SSH 密钥发我 Slack。"开发团队经常听到这句话。服务器访问紧急，新成员需要配置环境，部署在即却没有密钥。

但这句简单的话可能引发严重的安全事故。

SSH 密钥共享为什么特别危险

SSH 密钥不同于普通密码。它授予服务器的完整访问权限。

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

SSH 密钥泄露意味着服务器上的所有文件、数据库、代码都可被访问，这与单个密码泄露完全不同。

团队需要共享 SSH 密钥的场景

• 共享服务器访问：团队都需要访问的 Staging/生产服务器
• 部署密钥：CI/CD 流水线使用的密钥
• SSL 证书：负责人变更时的证书更新
• API Secret：第三方服务集成的认证信息
• 数据库凭证：紧急故障响应

危险的共享方式

1. Slack/钉钉私信

聊天记录永久存储在服务器上。任何人搜索"ssh"或"key"就能找到之前共享的密钥。

2. 邮件

永久保存在邮件服务器上，一次转发就失控。

3. 共享云盘/Notion

细粒度权限控制困难，同步后本地残留副本。

4. 提交到 Git 仓库

最危险。Git 历史中永久保留，即使删除文件也可从历史中恢复。

安全的共享方式

方式 1：LOCK.PUB 加密备忘录（一次性传递最佳选择）

1. 在 LOCK.PUB 创建加密备忘录
2. 粘贴 SSH 密钥或证书内容
3. 设置强密码
4. 将过期时间设为最短（1-4 小时）
5. 链接发 Slack，密码电话告知
6. 接收者本地保存密钥后，链接过期

优势：

• 密钥不以明文存储在任何持久服务器上
• 过期后不可访问
• 聊天记录中不残留密钥原文

方式 2：密钥管理器（大团队适用）

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

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

运营 SSH CA，为每个用户签发独立证书，从根本上消除密钥共享需求。

方式 4：个人密钥（最推荐）

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

必须共享时的检查清单

传递前

• 密钥权限范围是否已设为最小？
• 只读密钥是否足够？
• 能否设置 IP 限制？

传递时

• 密钥和密码是否通过不同渠道发送？
• 过期时间是否尽可能短？

传递后

• 确认接收者已安全存储密钥
• 确认共享链接/备忘录已过期
• 监控密钥使用日志

密钥轮换计划

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

DevOps 团队安全检查清单

• 所有服务器是否使用个人 SSH 密钥？
• 共享密钥是否已配置 IP 限制？
• 离职员工的密钥是否立即失效？
• 是否建立了密钥轮换计划？
• SSH 密钥是否从未提交到 Git 仓库？
• 聊天记录中是否有明文密钥残留？
• 敏感信息传递是否使用带过期的渠道？

总结

SSH 密钥和证书是服务器安全的命脉。通过 Slack 私信或邮件发送就像把家钥匙贴在公告栏上。尽可能签发个人密钥，必须共享时使用最短过期时间的加密备忘录。

立即创建加密备忘录，安全传递 SSH 密钥。

创建加密备忘录