Shell 脚本中如何安全存储数据库密码避免明文？

在 Shell 脚本中安全存储数据库密码，核心原则是“最小权限”与“分离存储”。对于 MySQL/MariaDB，推荐使用加密登录路径（mysql_config_editor）或权限受限的配置文件（~/.my.cnf）；对于 PostgreSQL，使用 .pgpass 文件。严禁将密码硬编码在脚本或命令行参数中。

先说结论：明文密码绝不应出现在脚本代码或命令行参数里，优先采用配置文件权限控制或专用凭证管理工具。

• 先判断：确认当前脚本是否包含明文密码，检查文件权限是否为他人可读。
• 优先做：将密码移至权限严格的配置文件（chmod 600）或使用 mysql_config_editor 加密存储。
• 再验证：通过进程列表检查密码是否泄露，并测试脚本能否正常连接数据库。

方案对比与适用范围

本文主要以 MySQL/MariaDB 为例，PostgreSQL 等数据库原理类似。不同方案的安全性对比如下：

• 配置文件（~/.my.cnf）：密码仍为明文存储，但通过操作系统权限（chmod 600）保护。适用于一般内部环境，不满足高等级安全合规（如等保）要求。
• 加密登录路径（mysql_config_editor）：密码存储在加密文件（~/.mylogin.cnf）中，安全性更高。适用于生产环境。
• 凭证管理工具（Vault/CI/CD Secrets）：密码不落地，运行时动态注入。适用于高安全需求及自动化流水线。

MySQL 安全配置实操

方案一：加密登录路径（推荐）

MySQL 5.6.6+ 版本支持加密存储凭证，凭证文件默认存储在 ~/.mylogin.cnf。注意该文件与当前用户及主机绑定，备份还原时需小心权限问题。

# 设置加密登录路径，执行后会提示输入密码（输入时不显示）
mysql_config_editor set `--login-path`=local `--user`=root `--password` `--host`=localhost# 脚本中调用时不再需要 -p 参数
mysql `--login-path`=local -e "SELECT 1;"

方案二：受限配置文件（通用）

在用户主目录下创建 .my.cnf 文件，内容如下：

[client]
user=db_user
password=YourSecurePassword
host=localhost

立即执行权限限制命令，确保仅所有者可读写：

chmod 600 ~/.my.cnf
chown $(whoami):$(whoami) ~/.my.cnf

脚本错误处理与验证

在 Shell 脚本中连接数据库时，必须增加错误处理逻辑，避免脚本在连接失败后继续执行导致数据不一致。

#!/bin/bash# 执行 SQL 并检查退出状态
if ! mysql `--login-path`=local -e "SELECT 1;" > /dev/null 2>&1; thenecho "[ERROR] Database connection failed"# 可在此处添加告警通知逻辑exit 1
fiecho "[INFO] Database connection successful"
# 继续执行后续业务逻辑

验证步骤：

1. 检查文件权限：执行 ls -l ~/.my.cnf 或 ls -l ~/.mylogin.cnf，确认权限为 -rw------- (600)。
2. 检查进程泄露：脚本运行期间，新开终端执行 ps -ef | grep mysql，确认输出中不包含密码字符串。
3. 测试连接：手动执行修改后的脚本，确认能成功连接且无密码提示报错。

PostgreSQL 简要方案

PostgreSQL 客户端支持 ~/.pgpass 文件存储密码。格式为 hostname:port:database:username:password。

# 创建文件
echo "localhost:5432:mydb:myuser:mypassword" > ~/.pgpass# 必须设置权限为 600，否则客户端会忽略该文件
chmod 600 ~/.pgpass

CI/CD 环境凭证注入

在 Jenkins、GitLab CI 或 GitHub Actions 中，不建议使用配置文件，应利用平台提供的秘密管理功能：

• 配置秘密变量：在 CI/CD 平台设置 DB_PASSWORD 等变量，标记为 Protected/Masked。
• 脚本引用：在 Shell 脚本中通过环境变量读取，如 mysql -u user -p$DB_PASSWORD。
• 注意：即便如此，命令行参数仍可能出现在进程列表。更优解是使用支持环境变量读取密码的客户端配置或专用 Secret 工具。

常见风险与排查

1. 根用户与普通用户混淆

如果用 root 用户创建了配置文件，但脚本是用普通用户通过 sudo 或 cron 运行的，普通用户可能无法读取 root 主目录下的配置文件。确保配置文件属于运行脚本的账户。

2. 配置文件权限被重置

某些自动化部署工具或备份还原操作可能会重置文件权限。在部署流程中需加入权限检查步骤，确保 chmod 600 始终生效。

3. 备份风险（.mylogin.cnf）

加密登录文件 ~/.mylogin.cnf 包含加密密钥，直接复制到其他机器可能无法解密。备份时需注明依赖关系，或优先使用配置文件方案便于迁移。

4. 历史命令记录

在终端手动输入密码测试时，密码可能被保存在 ~/.bash_history 中。测试完成后，建议清理历史记录或设置 HISTIGNORE 忽略敏感命令。

原文链接：https://www.zjcp.cc/ask/10998.html