在 Linux 系统中，直接查询已存在的数据库用户密码的行为存在严重的安全隐患，并且大多数现代数据库管理系统出于安全考虑，默认不会存储或允许查看原始密码，本文的核心目标是帮助您理解这一限制，并提供以下两类关键场景的解决方案：一是验证账户权限与加密后的认证信息；二是当您完全遗忘密码时，如何通过安全的方式重置密码以重新获得访问权，我们将围绕常见的开源数据库（MySQL/MariaDB、PostgreSQL）展开详细说明，并附上操作对比表及常见问题解答。
📌核心前提：为何不能直接“查询”密码？
- 安全最佳实践：数据库从不保存明文密码，所有密码均经过不可逆的哈希算法（如
SHA256,SCRAM-SHA-256）处理后存储，这意味着即使数据库管理员也无法从存储值反向推导出原始密码。 - 审计追踪：任何试图“窥视”密码的行为都会被记录在审计日志中，属于高风险违规操作。
- 替代方案：正确的做法是通过
ALTER USER命令修改密码，或在紧急情况下执行密码重置流程。
🔍场景一：验证用户是否存在及关联的加密认证信息 (非明文!)
此操作仅能证明该用户使用了何种认证插件及其参数状态,绝非真实密码。
✅适用于 MySQL/MariaDB
- 登录 MySQL 命令行客户端：
mysql -u root -p # 输入你的root密码进入
- 查询用户表
mysql.user：SELECT Host, User, authentication_string, plugin FROM mysql.user WHERE User = '目标用户名';
authentication_string: 这是经过哈希处理后的密码字符串（二进制数据转为十六进制展示），不是明文。plugin: 显示使用的认证协议（如caching_sha2_password,mysql_native_password），不同插件生成的哈希格式不同。
| 字段名 | 说明 | 能否看到明文密码？ |
|---|---|---|
Host |
允许连接的来源主机地址 | ❌ |
User |
数据库用户名 | ❌ |
authentication_string |
经哈希处理后的密码密文 | ⚠️ (非明文) |
plugin |
使用的认证机制 | ❌ |
account_locked |
账户是否被锁定 | ❌ |
注意: 如果结果是空，表示该用户不存在；若存在但无有效
authentication_string，则此用户未设置密码（需立即修复！）。
🔧场景二：忘记密码 → 安全重置流程 (以 MySQL/MariaDB 为例)
这是最常见且合法的“找回”密码方式，以下是标准步骤：
| 步骤 | 操作命令/动作 | 说明 |
|---|---|---|
| 1️⃣ | sudo systemctl stop mysql (或 service mysql stop) |
首要安全措施：停止数据库服务以防止新连接干扰。 |
| 2️⃣ | sudo mysqld_safe --skip-grant-tables & |
以特殊模式启动数据库服务，跳过权限检查（仅用于紧急修复）。 |
| 3️⃣ | mysql -u root |
无需密码即可登录 root 账户。 |
| 4️⃣ | FLUSH PRIVILEGES; |
刷新权限缓存，使后续更改生效。 |
| 5️⃣ | USE mysql; |
切换到存放用户信息的 mysql 库。 |
| 6️⃣ | UPDATE user SET authentication_string = PASSWORD('新密码'), password_expired='N' WHERE User='目标用户' AND Host='主机名'; |
更新指定用户的密码为新的哈希值。PASSWORD() 函数会自动生成对应插件所需的哈希。password_expired='N' 确保密码不过期。 |
| 7️⃣ | exit; |
退出客户端。 |
| 8️⃣ | sudo systemctl start mysql (或 service mysql start) |
恢复正常启动数据库服务。 |
| 9️⃣ | 测试新密码: mysql -u 目标用户 -p → 输入新密码 |
验证是否能正常登录。 |
重要警示: 此方法赋予你对系统的完全控制权，请务必仅由可信人员操作，并在完成后立刻恢复正常的安全策略，生产环境建议优先联系 DBA 团队处理。
🐟场景三：PostgreSQL 的处理方式
PostgreSQL 的理念类似，更加注重角色管理。
📚查看角色定义 (不含密码)
-psql 终端内执行 du+ role_name # 显示角色属性及成员关系，但不包含密码 SELECT FROM pg_shadow WHERE usename = 'role_name'; # pgbouncer 等工具可能创建此视图，但仍不推荐依赖
PostgreSQL 自身也不提供查看明文密码的途径。
🛠️重置丢失的密码
- 编辑配置文件: 找到
postgresql.conf，设置password_encryption = 'scram-sha-256'(或其他所需算法)。 - 重启 PostgreSQL:
sudo systemctl restart postgresql。 - 切换到 postgres OS 用户:
su postgres。 - 启动 psql:
psql。 - 执行 SQL:
ALTER ROLE role_name WITH PASSWORD 'new_secure_password';
- 退出并测试:
exit;→psql -U role_name -d database_name。
⚖️相关问答 FAQs
Q1: 我明明是 DBA，为什么还不能直接看别人的密码？
A: 这是强制性的安全设计，想象一下，如果任何人只要能连上数据库就能看到所有账号的密码，这将导致灾难性的泄露风险，数据库系统只信任你在首次登录时提供的凭证是正确的，之后的所有操作都必须基于已有权限进行授权变更，而不能反向解密历史记录，这是保护用户隐私和系统安全的基石，如果你确实需要知道某个业务的登录凭据，应当联系应用所有者或上级主管获取初始配置信息。
Q2: 如果我不是 root/postgres 超级用户怎么办？还能救急吗？
A: 很遗憾，普通用户没有任何途径绕过权限体系去修改或查看他人的密码，唯一的解决办法是请求具有足够权限的人员（如 root 或拥有 CREATE ROLE 权限的高阶用户）协助你完成上述重置流程，在某些严格的环境中，甚至需要提交工单并由多人审批后方可进行此类敏感操作，这也是企业级环境中标准的职权分离控制措施。
在 Linux 环境下管理数据库密码的核心原则是：永远不要期望能看到明文密码，而是学会如何安全地修改和管理它们，当你遇到密码遗失的情况时，请严格按照官方文档提供的应急流程操作，并始终将安全性放在首位，对于日常运维，建议启用更强的密码策略、定期轮换密码，并
原创文章，发布者：酷盾叔，转转请注明出处：https://www.kd.cn/ask/105335.html
