在KingbaseES数据库运维过程中给业务系统创建普通权限账号时按照官方文档执行create user命令后却遇到所有新建账号全部认证失败、提示密码错误的问题但内置的system管理员账号却能正常登录。本案例来自金仓社区核心原因是sys_hba.conf指定的认证方法与password_encryption决定的密码存储格式不匹配——服务端按SCRAM算法校验而库里存的是MD5哈希。排查过程和修复方案可直接复用帮你快速定位并解决同类新建用户无法登录的问题避免配置不匹配影响业务系统上线进度。故障现象数据库安装部署完成后使用自带默认管理员账号system通过管理工具、终端均可正常认证登录操作但通过管理界面或SQL命令手动新增的所有用户在登录时均认证失败提示账号密码错误所有自建用户均存在该问题无个别例外。你可以参考以下复现步骤确认是否遇到同类问题[kingbaselocalhost 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 [kingbaselocalhost bin]$ ./ksql -Uuser01 -h192.168.40.128 test ksql: error: could not connect to server: FATAL: password authentication failed for user user01 [kingbaselocalhost bin]$ ./ksql -Uuser01 test ksql: error: could not connect to server: FATAL: password authentication failed for user user01 [kingbaselocalhost bin]$ ./ksql -Uuser01 test -W Password: ksql: error: could not connect to server: FATAL: password authentication failed for user user01 [kingbaselocalhost 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. 确认是否存在限定仅初始化内置账号可登录的环境标识变量[kingbaselocalhost bin]$ echo $KINGBASE_PASSWORD [kingbaselocalhost bin]$ cat /home/kingbase/.encpwd #*:54321:*:system:MTIz [kingbaselocalhost 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:glhJWJB2LjBBkjxPDpj3A$t1XLuecFHTxUZNul7OEsdCxHVvf8BRfDsUUtUOGDWKQ:gf4fIwLguh20rAlfUs6z3TRA8k878C18/5rmXJL8lA 8 | sso | SCRAM-SHA-256$4096:zzhPSXSwqdhyxHqpMSwUtg$OM84fK6HwdCh9gcu1kwJdpLEWYofkXERA0obyz1v8: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决定密码怎么验。两者必须兼容认证才能通过认证方法 \ 存储格式MD5SCRAM-SHA-256SM3md5通过通过通过scram-sha-256失败通过失败sm3失败通过通过次故障正好落在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-2562. 重载数据库配置生效不需要重启服务# 在线重载配置 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. 重新登录验证所有新建账号认证正常[kingbaselocalhost 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 md52. 重载数据库配置生效# 在线重载配置 ksql -U system -d test -c SELECT sys_reload_conf(); # 如果重载不生效可以重启数据库 sys_ctl restart -D /你的data目录路径3. 确认现有账号可以正常登录# md5认证方式兼容MD5、SCRAM-SHA-256、SM3三种存储格式 # 因此已有账号通常无需重置密码直接验证即可 [kingbaselocalhost bin]$ ./ksql -Usystem test Password for user system: test [kingbaselocalhost 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-2562. 检查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 持续整理社区里高频出现的坑与解法