AI Agent 建数据库账号全部认证失败：sys_hba 与 password_encryption 配置不匹配

在KingbaseES数据库运维过程中，给业务系统创建普通权限账号时，按照官方文档执行create user命令后，却遇到所有新建账号全部认证失败、提示密码错误的问题，但内置的system管理员账号却能正常登录。本案例来自金仓社区，核心原因是sys_hba.conf指定的认证方法与password_encryption决定的密码存储格式不匹配——服务端按SCRAM算法校验，而库里存的是MD5哈希。排查过程和修复方案可直接复用，帮你快速定位并解决同类新建用户无法登录的问题，避免配置不匹配影响业务系统上线进度。

故障现象

数据库安装部署完成后，使用自带默认管理员账号system通过管理工具、终端均可正常认证登录操作；但通过管理界面或SQL命令手动新增的所有用户，在登录时均认证失败，提示账号密码错误，所有自建用户均存在该问题，无个别例外。你可以参考以下复现步骤确认是否遇到同类问题：

[kingbase@localhost bin]$ ./ksql -Usystem -h192.168.40.128 test Password for user system: Type "help" for help. test=# test=# create user user01 password '12345678ab'; CREATE ROLE test=# test=# \c test user01 FATAL: password authentication failed for user "user01" Previous connection kept test=# \du List of roles Role name | Attributes | Member of ------------|------------------------------------------------------------|----------- kcluster | Cannot login | {} sao | No inheritance, Create role | {} sao_oper | No inheritance, Cannot login | {} sao_public | No inheritance, Cannot login | {} sso | No inheritance, Create role | {} sso_oper | No inheritance, Cannot login | {} sso_public | No inheritance, Cannot login | {} system | Superuser, Create role, Create DB, Replication, Bypass RLS | {} user01 | | {} test=# \q [kingbase@localhost bin]$ ./ksql -Uuser01 -h192.168.40.128 test ksql: error: could not connect to server: FATAL: password authentication failed for user "user01" [kingbase@localhost bin]$ ./ksql -Uuser01 test ksql: error: could not connect to server: FATAL: password authentication failed for user "user01" [kingbase@localhost bin]$ ./ksql -Uuser01 test -W Password: ksql: error: could not connect to server: FATAL: password authentication failed for user "user01" [kingbase@localhost bin]$

这类问题在业务系统批量上线时触发概率极高：大部分企业日常运维习惯直接使用内置system账号操作，很少批量创建普通权限用户，直到业务上线前集中分配账号时才会暴露配置冲突问题，如果没有提前排查，会直接导致业务系统所有数据库请求失败，影响上线进度。

专项排查步骤

你可以按照以下顺序逐步排查，每一步的命令和输出均可直接复现，快速定位问题根因：

1. 校验data目录sys_hba.conf认证配置文件

首先排查访问控制规则，确认没有对新建用户做IP、账号段拦截，定位data目录下的sys_hba.conf文件，核查以下内容：

1. 核对文件内客户端认证策略、访问权限放行规则，确认未对新建用户做IP / 账号段拦截；

2. 对比初始化内置账号对应的访问规则，查看是否缺少新建用户匹配的认证条目；

3. 检查认证方式配置（密码认证 / 信任认证）是否统一，是否存在区分初始化账号与新建用户的差异化拦截规则；

4. 修改配置后重载认证服务，确保配置生效，重新测试新建用户登录。

# TYPE DATABASE USER ADDRESS METHOD # "local" 只能用于UNIX域套接字 local all all scram-sha-256 # IPv4 本地连接: host all all 127.0.0.1/32 scram-sha-256 host all all 0.0.0.0/0 scram-sha-256 # IPv6 本地连接: host all all ::1/128 scram-sha-256 host all all ::0/0 scram-sha-256 # 流复制连接规则 local replication all trust host replication all 127.0.0.1/32 scram-sha-256 host replication all ::1/128 scram-sha-256

从上述配置可以看到，所有非复制场景的连接认证方式均为scram-sha-256，没有针对特定用户的拦截规则，排除访问控制策略导致的登录失败问题。

2. 检查系统相关认证环境变量

接下来排查认证相关的环境变量和免密配置，确认不存在限定仅内置账号可登录的规则：

1. 遍历系统全局环境变量、应用服务进程环境变量，筛选账号认证、密码加密相关环境参数；

2. 确认是否存在限定仅初始化内置账号可登录的环境标识变量；

[kingbase@localhost bin]$ echo $KINGBASE_PASSWORD [kingbase@localhost bin]$ cat /home/kingbase/.encpwd #*:54321:*:system:MTIz [kingbase@localhost bin]$

可以看到KINGBASE_PASSWORD环境变量为空，.encpwd文件中仅预置了system账号的加密凭证，不会影响新建用户的登录认证，排除环境配置干扰。

3. 核查系统表及密码存储文件

接下来登录数据库查询用户系统表，对比内置用户、新建用户的密码存储格式差异：

1. 登录数据库，读取用户系统表，对比内置用户、新建用户全字段差异：账号状态、权限标识、密码存储字段、激活标记；

2. 定位系统密码持久化存储文件，查看新建用户密码写入是否完整、无截断、无写入失败；

3. 确认新建用户记录是否正常写入系统表，无缺失字段、空值异常；

4. 校验账号启用状态，排查新建用户默认禁用、未授权等状态拦截问题。

test=# select oid,rolname,rolpassword from sys_authid where rolname in ('sao','sso','system','user01'); oid | rolname | rolpassword -------|---------|-------------------------------------------------------------------------------------------------------------- 9 | sao | SCRAM-SHA-256$4096:glhJWJB2LjBBkj+xPDpj3A==$t1XLuecFHTxUZNul7OEsdCxHVvf8BRfDsUUtUOGDWKQ=:gf4fI+wLguh20rAlfUs6z3TRA8k878C18/5rmXJL8lA= 8 | sso | SCRAM-SHA-256$4096:zzhPSXSwqdhyxHqpMSwUtg==$OM84f+K6HwdCh9gcu1kwJd+pLEWYofkXERA0obyz1v8=:jS5cn2Qj7ZfLRd39fr5yCg9SVlNtkTTqBfowtgS7hzo= 10 | system | SCRAM-SHA-256$4096:CY8iYjuIpNgsiOZ0SAsM9A==$3gar2RW6XwVgnAseSXK/qpHoigBvlBBqRGsk9uQ859I=:jadBTrTToll8BOF0GDXdYIkl35eGJcGUczZG51xIY5I= 16385 | user01 | md52ee7e038c50f7aa237809ee6b0f3b06f (4 rows)

从查询结果可以看到明显差异：初始化自带的system、sao、sso用户的密码哈希以`SCRAM-SHA-256$`开头，而手动新建的user01用户密码哈希为纯MD5串。`sys_authid.rolpassword`开头的前缀就标明了该密码的存储算法，三种格式分别以`SCRAM-SHA-256$`、`md5`、`sm3`开头。

如果是通过自动化脚本批量创建账号，建议将该格式校验逻辑写入自动化账号创建脚本，账号创建完成后立即断言rolpassword前缀与预期存储算法一致，无需等待业务上线运行后再通过连接报错排查问题。

4. 核对password_encryption密码加密配置

接下来查询全局密码加密参数，确认新建用户的加密规则：

1. 查询全局参数password_encryption，确认当前生效的密码加密算法（MD5/SHA256/SCRAM等）；

2. 对比初始化脚本创建内置用户时使用的加密逻辑，与后台新增用户加密逻辑是否一致；

test=# show password_encryption ; password_encryption --------------------- md5 (1 row)

可以看到全局加密参数设置为md5，与sys_hba.conf中配置的scram-sha-256认证方式完全不匹配，至此问题根因完全定位。

这里需要区分两个容易混淆的概念：`password_encryption`决定密码**怎么存**，`sys_hba.conf`的METHOD决定密码怎么验。两者必须兼容，认证才能通过：

次故障正好落在`scram-sha-256`认证 + MD5存储的"失败"格子里。另外注意兼容性是有方向的：`scram-sha-256`格式的密码可以走`md5`认证方法，反过来则不行。

故障根因分析

1.认证配置与加密参数冲突：sys_hba.conf配置所有连接强制采用scram-sha-256认证校验，但数据库全局参数password_encryption = md5，手动新建用户修改密码时按参数生成MD5格式哈希，存储到sys_authid表中。

2.两种格式无法互通校验：登录时服务端按hba规则使用SCRAM算法校验密码，而新建用户库内存储的是MD5哈希，算法不匹配，直接返回认证失败。这一点可由上一步的哈希前缀对比直接印证。

3.内置账号为什么不受影响：system、sao、sso 三个账号的哈希都是SCRAM-SHA-256$4096:...格式，与新建用户的MD5哈希不同。根本原因是这些账号被设置密码的时间点早于password_encryption被改成md5的时刻——密码哈希的格式由设置密码那一刻的参数值决定，sys_authid里存的是哈希而不是明文，改参数不会去动已有账号的哈希（哈希不可逆，本来也无法从MD5反推回scram格式）。所以这不是"内置账号有特殊待遇"，同样时间点建的普通账号会是一样的结果。

4.本地.encpwd加密文件仅预影响免密登录：该文件在宿主目录下以密文记录免密登录信息，不参与密码认证的校验过程，不影响本次认证结果。

如果你的数据库实例开启了登录失败次数限制或账号自动锁定策略，业务端的自动重试机制可能在短时间内触发多次失败请求，将普通的认证失败升级为账号被锁定的更严重故障，具体锁定规则需要你结合自身实例的配置核对。同时持续发起的大量认证失败请求会被写入审计日志，可能触发安全设备的异常访问告警，干扰正常的风险识别流程。

分步修复方案

你可以根据业务场景选择以下两种修复方案，本文案例中两种方案均可复现修复效果：

方案1：统一全局加密算法为scram-sha-256（生产环境优先推荐）

该方案与sys_hba.conf当前的认证方式保持一致，不需要改动认证配置，适合生产环境和长期自动运行的业务账号。长期运行的业务系统数据库凭据通常以配置文件、环境变量或密钥管理服务的形式存储，相比人工单次输入口令的暴露面更大，因此更需要使用高强度的口令哈希算法抵御泄露风险。从机制上看，SCRAM-SHA-256 带盐值和迭代次数，而 MD5 是较早的单轮摘要算法、不带盐值，主流安全规范已不再推荐将 MD5 用于口令存储。

1. 修改数据库配置文件kingbase.conf，调整加密参数：

password_encryption = scram-sha-256

2. 重载数据库配置生效，不需要重启服务：

# 在线重载配置 ksql -U system -d test -c "SELECT sys_reload_conf();" # 验证是否更改成功 ksql -U system -d test -c "show password_encryption;" # 预期输出 password_encryption --------------------- scram-sha-256 (1 row)

3. 对所有已创建的异常账号重置密码，使新算法生效：

alter user user01 with password '12345678ab'; -- 批量重置所有MD5加密的账号可以使用以下语句 select 'alter user '||rolname||' with password ''你的默认密码'';' from sys_authid where rolpassword like 'md5%';

4. 重新登录验证，所有新建账号认证正常：

[kingbase@localhost bin]$ ./ksql -Uuser01 test Password for user user01: test=>

坑点提示：修改password_encryption和password_sys_hba.conf都只影响**之后**新设置的密码，已有账号的哈希格式不会自动改变（哈希不可逆，也无法从MD5自动转成SCRAM）。不重置密码就直接连，仍然会认证失败。操作前需要提前通知相关业务方。

方案2：统一hba认证规则为md5（仅适合测试环境临时使用）

如果测试环境不需要高安全等级，不想重置已有账号密码，可以选择该方案，生产环境不推荐使用。

1. 修改数据库规则配置文件sys_hba.conf，调整METHOD字段为md5：

# TYPE DATABASE USER ADDRESS METHOD # "local" 只能用于UNIX域套接字 local all all md5 # IPv4 本地连接: host all all 127.0.0.1/32 md5 host all all 0.0.0.0/0 md5 # IPv6 本地连接: host all all ::1/128 md5 host all all ::0/0 md5 # 流复制连接规则 local replication all trust host replication all 127.0.0.1/32 md5 host replication all ::1/128 md5

2. 重载数据库配置生效：

# 在线重载配置 ksql -U system -d test -c "SELECT sys_reload_conf();" # 如果重载不生效可以重启数据库 sys_ctl restart -D /你的data目录路径

3. 确认现有账号可以正常登录：

# md5认证方式兼容MD5、SCRAM-SHA-256、SM3三种存储格式， # 因此已有账号通常无需重置密码，直接验证即可 [kingbase@localhost bin]$ ./ksql -Usystem test Password for user system: test=> [kingbase@localhost bin]$ ./ksql -Uuser01 test Password for user user01: test=>

坑点提示：MD5 是较早的单轮摘要算法，用于口令存储已不符合当前主流安全实践；把认证方式改成md5虽然能让存量账号立刻恢复登录，但代价是认证强度下降。建议仅作临时兼容手段，不要用于生产环境，尤其不要用于配置长期运行的业务账号。另外，如果改用`sm3`这类国密认证方式，则只兼容SM3格式的存储，跨算法族仍然需要重置密码——兼容性是分算法族的，不是一律向后兼容。

为什么这个问题在给 AI Agent 建账号时尤其常见

如果你需要对接AI Agent场景，为其分配数据库访问账号，这类配置冲突的影响会被进一步放大，主要原因如下：

1. 人工创建普通账号失败会立刻发现并求助排查，而AI Agent的账号通常是程序化、批量创建，往往是Agent上线运行时才会发现问题，影响范围更大、发现时间更晚。

2. AI Agent通过数据库驱动发起连接时，报错仅返回通用的“认证失败”提示，不会返回哈希格式不匹配的细分原因，问题定位链路更长，容易影响Agent业务链路的上线进度

3. AI Agent的数据库凭据通常存储在配置文件、环境变量或密钥管理服务中，相比人工单次输入口令的暴露面更大，对加密算法的安全性要求更高。

4. 如果你的数据库实例开启了登录失败次数限制或账号自动锁定策略，AI Agent的自动重试机制可能在短时间内触发多次失败请求，将普通的认证失败升级为账号被锁定的更严重故障，具体锁定规则需要你结合自身实例的配置核对。

5. AI Agent持续发起的大量认证失败请求会被写入审计日志，可能触发安全设备的异常访问告警，干扰正常的风险识别流程。

给 AI Agent 配置数据库账号前的专项检查清单

你可以保存以下清单，在数据库初始化、给AI Agent创建账号前逐一核对，提前规避同类问题：

1. 数据库初始化完成后第一时间执行show password_encryption;，确认加密算法为scram-sha-256

2. 检查sys_hba.conf所有非replication条目的METHOD字段，确认与现存账号的密码存储格式兼容（不是简单要求两者"相等"，而是满足兼容性矩阵）

3. 生产环境禁止将sys_hba.conf的METHOD设置为trust，避免无密码访问风险

4. 新建用户后执行select rolname,rolpassword from sys_authid where rolname = '新建用户名';，确认哈希格式和存储算法匹配

5. 给AI Agent创建账号前，先手动测试账号登录是否正常，再配置到Agent的连接参数中

6. 给AI Agent的账号仅开放必要的表权限，禁止分配superuser、createrole、createdb等高权限

7. 每季度巡检sys_authid表，执行select rolname from sys_authid where rolpassword like 'md5%';筛查所有MD5格式密文的账号，批量重置为scram格式

8. 程序化校验新建Agent账号的rolpassword前缀与预期加密算法一致，避免手动校验遗漏

9. 核对实例登录失败次数限制、账号锁定策略，在Agent初始化配置阶段关闭不必要的自动重试，避免触发账号锁定

10. 确认Agent的数据库凭据存放于专用密钥管理服务或加密配置文件中，禁止明文存储在代码仓库、部署脚本内

11. 根据Agent的业务访问量级预留足够的数据库连接数配额，避免高频访问导致连接被拒绝

12. 配置Agent账号专属的审计规则，定期核查访问范围是否符合最小权限要求，及时回收多余权限

---------------------------------------------------------------------------------------------------------------------------------

本文案例整理自金仓社区真实反馈，排查过程与命令输出均已验证。

金仓社区的 KK ｜ 持续整理社区里高频出现的坑与解法