Linux服务器上并不存在一条直接显示数据库密码的命令，密码通常以哈希形式存储在数据库内部，需要从配置文件、环境变量或进程参数中寻找明文，若均无记录则需通过重置密码的方式解决。
作为运维人员,接手一台旧服务器时最头疼的事情，莫过于部署新功能却找不到数据库密码，即使有服务器的 root 权限，也无法用一句简单的命令把密码“打印”出来，这种设计源于安全机制，数据库仅保存密码的哈希摘要而非明文，与其抱怨，不如掌握一套系统的排查思路，从配置文件的蛛丝马迹到最后的强制重置手段，总有一种方式能解除危机。
最先排查的地方：配置文件中的连接串
大多数应用为了便于维护,会把数据库连接信息写在配置文件中，登录服务器后，建议先在应用目录下执行 grep -r "password" /www/wwwroot/ 或 grep -rn "数据库密码" /home/project/ 这类搜索命令，找出包含密码字段的文件，重心放在以下几个固定目录：
- PHP 项目：
.env文件、config/database.php或wp-config.php（WordPress 站点） - Java 项目：
application.yml或application.properties - Python 项目：
settings.py或config.ini - Node.js 项目：
process.env.DB_PASSWORD所引用的.env文件
一个实用技巧是,许多面板环境（如宝塔）会在 /www/wwwroot/站点目录/.env 中记录数据库账号和密码，直接打开这个文件往往能快速定位，如果项目使用了 Docker 部署，还需检查 docker-compose.yml 中的 environment 字段，或通过 docker inspect 容器名 查看容器的环境变量。
数据库自身的密码存储机制
若在应用配置中一无所获,需要理解 MySQL、PostgreSQL 等数据库的用户密码存储逻辑，在 MySQL 中，用户密码保存在 mysql.user 表的 authentication_string 字段，但这只是经过 SHA-2 算法加密的哈希串，并非原始密码，知道这个原理有助于我们理解：即使进入数据库执行
select user,host,authentication_string from mysql.user;，返回的也是一串无法逆向解密的乱码。
查看MySQL密码的常见误区
有相当一部分教程建议通过 skip-grant-tables 参数重置密码，这个操作确实可行，但流程需要谨慎，先停止 MySQL 服务，在配置文件 my.cnf 的 [mysqld] 段下添加 skip-grant-tables，然后重启服务，此时无需密码即可登录数据库，执行 flush privileges; 重新加载权限，再更新密码，但完成操作后务必移除该参数并再次重启服务，否则服务器将长期处于裸奔状态，存在较大的安全隐患。
从运行进程和环境变量中获取线索
有些程序为了避免代码中硬编码密码,选择通过环境变量注入，在 Linux 中，查看某个服务的运行环境可通过 cat /proc/进程PID/environ | tr ' ' 'n' | grep -i pass 获取，具体操作是先用 ps aux | grep java 找到 Java 进程的 PID，再读取该进程的环境变量。
另一个容易忽略的区域是 shell 历史记录，管理员在安装数据库时，往往会在命令行中临时输入过密码，执行 history | grep -i -E "mysql|psql|redis-cli" 可能会看到当时执行的完整命令，mysql -uroot -p'旧密码'，这便是直接获取密码的有效途径，需要注意的是，如果服务器开启了 history 时间戳功能，可以更精确地定位操作时段。
查看Redis密码的特殊性
Redis 的密码与 MySQL 不同，它的配置信息集中在 redis.conf 文件中，查看密码的命令为 grep requirepass /etc/redis/redis.conf，执行后返回的 requirepass yourpassword 就是明文密码，若文件中的 requirepass 字段为空，说明 Redis 未设置密码，仅允许本地回环地址访问，此时需要评估是否需补充安全策略（如绑定内网 IP）。
数据库账号密码找回的完整操作路径
当所有配置文件均无记录,且历史命令不完整时，最稳妥的方式是按数据库类型进行密码重置，以下为三款主流数据库的具体操作路径。
MySQL 8.0 重置密码
- 编辑
/etc/my.cnf，在[mysqld]区段追加skip-grant-tables - 执行
systemctl restart mysqld重启数据库 - 无密码登录：
mysql -uroot - 清空旧密码：
update mysql.user set authentication_string='' where user='root'; - 退出并删除
skip-grant-tables配置，重启服务 - 使用新密码登录：
alter user 'root'@'localhost' identified by '新密码';
PostgreSQL 修改密码流程
- 切换到 postgres 系统用户：
su - postgres - 进入命令行：
psql - 执行修改语句：
alter user postgres with password '新密码';
MongoDB 重置密码再生流程
MongoDB 的权限模型稍有不同，需先移除 --auth 参数重启，进入 admin 库后更新用户信息，操作顺序为：在配置文件中注释 auth=true，重启服务后执行 db.changeUserPassword('admin', '新密码')。
日常如何避免密码丢失的尴尬
既然密码找回过程如此繁琐,且每次重置都可能影响依赖数据库的应用连接，不如提前建立管理规范，建议在初始化服务器时做两件事：第一，将明文密码写入公司内部的密码管理平台（如 KeePass、Vault），而不是记录在个人笔记中；第二，检查应用是否支持配置热加载，确保调整密码后无需重启整个服务。
业内专家指出,数据库连接信息属于高敏凭证，应当遵循最小权限原则和定期轮换制度，多数大型互联网公司不会在生产环境中存储明文密码，而是将连接串交给配置中心统一托管，运维人员无需知晓具体的密码值，只需申请临时授权即可。
梳理几种不借助密码直接查询数据的方法
确实存在绕过密码查询数据库内容的路径,但建议仅在极端情况下使用，利用 MySQL 的 --init-file 参数在启动时自动执行 SQL 文件，将查询结果输出到临时表，这种方法要求对数据库文件有读取权限，且操作过程极其复杂。
与此相关的另一个场景是,服务器上的数据库密码遗忘，同时配置文件中写的是旧密码，此时不能仅重置数据库密码，还需同步修改所有应用的连接串，否则应用会因认证失败而无法启动，更合理的做法是先在所有配置文件中搜索旧密码，执行 find / -name ".env" 2>/dev/null | xargs grep -l "DB_PASSWORD" 定位所有受影响的项目，再统一替换新密码。
Q&A：linux服务器数据库密码查看常见疑问
问：linux怎么查看数据库密码是否被修改过？
在 MySQL 中可通过 mysqlbinlog 分析二进制日志中的 alter user 语句，在 PostgreSQL 中则查询系统日志中记录的认证失败信息，但更实际的做法是与应用上线时间进行比对，查看当时是否有运维人员执行过密码变更命令，任何数据库的密码修改操作都会在日志中留痕，若未开启相应日志级别，则无法追溯历史变更记录。
问：linux服务器上多个项目共用一套MySQL，密码存储在哪里？
各项目自身的配置文件中各自保存一份完整的连接串,这会导致一处修改、多处失效的现象，排查时可以在服务器上执行 grep -r "password" /www/wwwroot/ 进行全局搜索，找到所有引用同一数据库账号的项目，评估统一改造为环境变量引用的必要性，对于使用 Kubernetes 部署的服务，请优先检查 ConfigMap 和 Secret 资源，密码往往不是明文存在于 YAML 文件中，就是通过 base64 编码存储。
问：Docker容器中的数据库密码如何找回？
Docker 容器的理念是即用即弃，镜像内通常不会持久化配置文件，若容器还在运行，可通过 docker exec 容器名 env | grep MYSQL_ROOT_PASSWORD 查询创建时注入的环境变量，前提是创建者使用了 -e 参数，如果该变量未设置，则需进入容器内部执行交互式命令重置，行业共识认为，容器环境下的密码管理应交给编排平台（如 Swarm、K8s）的密钥系统，从源头上避免明文散落。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/linux%e6%9c%8d%e5%8a%a1%e5%99%a8%e6%80%8e%e4%b9%88%e6%9f%a5%e7%9c%8b%e6%95%b0%e6%8d%ae%e5%ba%93%e5%af%86%e7%a0%81%ef%bc%8c%e6%9c%89%e5%93%aa%e4%ba%9b%e6%96%b9%e6%b3%95%ef%bc%9f/
