API密钥、数据库密码、SSH密码：32-64位高强度随机密码的生成与保管

如果你管理过一台云服务器，八成见过这样的场景：数据库密码设成"Admin123456"，API 密钥直接写在代码里，SSH 口令用姓名缩写加手机号。这些密码短期内不会出事，但它们是整个系统里最容易被忽略、一旦出事代价最高的一环。

这篇文章聊聊机器凭据（API 密钥、数据库密码、SSH 口令、访问令牌）为什么必须用 32 位以上随机密码，以及怎么生成、怎么保管。

一、机器密码和人用密码，标准为什么不一样

网站账号密码是"给人输入的"，要考虑记忆和输入成本；机器密码完全不同：

• 没人会去敲它：密钥和连接密码由程序读取，再长再怪都不影响使用；
• 长期有效：数据库连接密码、API 密钥往往几个月甚至几年不换，暴露窗口期长；
• 往往带权限：API 密钥可能直通你的云账单，数据库密码可能直通全量用户数据；
• 可能落在日志里：一次配置错误，密钥就可能出现在错误日志、构建日志里。

所以行业通行做法是：机器凭据一律 32 位以上、全字符随机。32 位混合字符的熵值超过 200 bits，暴力破解在数学上不可行；64 位则是密钥类场景（如加密密钥、签名密钥）的常规配置。

二、API 密钥怎么生成

以本站为例，生成一个合格的 API 密钥只需要：

1. 打开在线密码生成器，长度设 32-64 位；
2. 字符类型全选（大小写 + 数字 + 符号）；
3. 生成后复制，粘贴到服务端的密钥存储（环境变量或密钥管理系统），不要直接贴进代码。

这里有一个只有"本地生成"工具才有的优势值得多说一句：本站生成密码时数据完全不出浏览器，不会像某些在线 API 那样把密钥请求记录在服务器日志里——密钥这种东西，越少人经手越安全。你可以在浏览器开发者工具的 Network 面板里验证：点"生成密码"时没有任何网络请求。

三、数据库密码怎么设

MySQL、PostgreSQL、Redis 等数据库的连接密码，建议 32 位起步。设置时注意几点：

• 开发库和生产库密码分开，不要一套密码打天下；
• 每个库一个独立账号，权限最小化，别图省事全用 root；
• 密码存放在环境变量或 .env 文件里，确认 .env 在 .gitignore 里——GitHub 上每天都有因为 .env 被提交而泄露的数据库密码；
• 使用连接池和配置管理工具（如 Docker Secrets、K8s Secret）时，让密钥从环境注入，而不是写死在配置里。

四、SSH 密码和密钥口令

SSH 涉及两类"密码"，别混淆：

• 服务器用户密码（root/普通用户登录密码）：建议 32 位随机密码，且只作为应急通道。日常登录用下面的密钥方式。
• SSH 密钥的 passphrase：用 ssh-keygen 生成密钥对时设置的私钥口令，建议 16-32 位随机密码。它保护的是你的私钥文件——私钥本身再安全，没有口令就等于裸奔。

实践上，服务器建议直接禁用密码登录、只留密钥认证（PasswordAuthentication no），密码登录是暴力破解脚本最爱的目标。但保留一个 32 位随机密码作为带外应急入口（比如密钥丢失、控制台救援模式），是很多运维团队的保命配置。

五、保管规范：密钥不落代码，不进日志

生成了高强度密钥只完成一半，保管才是另一半。几条硬规矩：

• 不写进代码仓库：密钥进 Git 历史就是永久泄露，改密码都救不回来；
• 用环境变量或密钥管理服务：小项目用 .env，团队项目用 Vault、AWS Secrets Manager、云厂商的密钥托管；
• 日志脱敏：打印配置时把密码字段打码，password=*** 而不是明文；
• 定期轮换：核心密钥（云厂商、支付）建议 90 天轮换一次，数据库密码至少半年一次；
• 集中管理：把这些密钥也存进密码管理器（Bitwarden、KeePassXC 都支持），别散落在微信文件传输助手和备忘录里。

最后一条尤其重要：我们见过太多"服务器密码存在手机备忘录"的案例——手机一丢，等于把生产环境的钥匙一起丢了。

六、常见问题