Another.Redis.Desktop.Manager 连接 Redis 时用户名密码登录失败？

Question

Another.Redis.Desktop.Manager（ARDM）连接 Redis 时用户名密码登录失败，常见原因有三：一是 Redis 6.0+ 启用 ACL 后未正确配置默认用户（default）权限或未启用 `requirepass` 兼容模式；二是 ARDM 当前版本（v1.2.x 及更早）**仅支持 Redis 6+ 的 `AUTH ` 简单认证，不支持 `AUTH ` 的双参数 ACL 认证方式**，若 Redis 配置了非 default 用户（如 `user admin on >mypass ~* &* +@all`），ARDM 将认证失败；三是连接字符串中用户名被错误填写（如填入 `admin`），而 ARDM 实际忽略用户名字段，仅使用密码字段进行 `AUTH `，导致服务端拒绝。解决方案：确认 Redis 使用 `requirepass` 配置（而非纯 ACL 用户），或降级至兼容模式（`acl default on >mypass ~* &* +@all` 并确保 `default` 用户已启用），同时在 ARDM 连接窗口中**仅填写密码，用户名栏留空**。

Answer 1

```html

一、现象层：连接失败的直观表现

用户在 Another.Redis.Desktop.Manager（ARDM）v1.2.x 中填写 host:port、用户名 admin 与密码 mypass 后点击“连接”，界面长时间无响应或弹出 NOAUTH Authentication required / ERR invalid password 错误。该现象在 Redis 6.0+ 部署环境中高频复现，但使用 redis-cli -h xxx -p xxx -a mypass 命令却可成功登录——说明服务端认证逻辑正常，问题根植于客户端兼容性与协议理解偏差。

二、协议层：Redis 认证机制演进与 ARDM 的能力边界

Redis 6.0 引入 ACL（Access Control List），支持双参数 AUTH <username> <password> 和单参数 AUTH <password> 两种模式。而 ARDM v1.2.x 及更早版本仅实现 RESP 协议中对 AUTH <password> 的解析（即传统 requirepass 兼容路径），其源码中认证调用固定为：
await db.Connection.GetDatabase().GetServer(host, port).AuthenticateAsync(password);
——完全忽略用户名字段，也未构造 AUTH admin mypass 指令。

三、配置层：Redis 端三大典型错误配置场景

序号	错误配置	对应命令示例	ARDM 行为
1	仅启用 ACL 用户，禁用 default	ACL SETUSER admin on >mypass ~* &* +@all ACL SETUSER default off	返回 NOAUTH：因 default 被禁用，单参数 AUTH 失败
2	启用 requirepass，但同时存在 ACL 规则冲突	requirepass mypass ACL SETUSER default reset ~* &* +@all	可能成功（依赖 Redis 版本补丁），但属非标准混用，易引发权限降级
3	用户名栏填入非 default 用户名	ARDM UI 中 username=“admin”	字段被静默丢弃；若服务端 default 已 disable，则认证必然失败

四、诊断流程：五步精准定位问题根源

1. 检查 Redis 日志：tail -f /var/log/redis/redis-server.log，搜索 Client sent AUTH command with wrong number of arguments 或 User 'admin' not found
2. 进入 redis-cli，执行 ACL LIST，确认 user default on 是否存在且启用
3. 执行 CONFIG GET requirepass，判断是否启用传统密码模式
4. 运行 ACL WHOAMI（需先 AUTH 成功），验证当前上下文用户身份
5. 抓包验证：使用 tcpdump -i lo port 6379 -A 观察 ARDM 发送的 AUTH 命令是否为单参数

五、解决方案：生产环境推荐的三种落地路径

✅ 方案 A（推荐｜最小变更）：启用 default 用户并赋予等效权限
redis-cli ACL SETUSER default on >mypass ~* &* +@all
→ 此时 ARDM 使用单参数 AUTH 即可命中 default 用户，无需修改任何客户端代码。

✅ 方案 B（兼容旧习惯）：回退至 requirepass 模式
注释或删除所有 ACL 相关配置行，仅保留：
requirepass mypass
→ 完全兼容 ARDM v1.2.x 及所有历史工具链，适合快速恢复业务。

✅ 方案 C（面向未来）：升级 ARDM 并启用 ACL 显式认证
等待或手动编译 ARDM v1.3+（已合并 PR #482），支持双参数 AUTH；同时配置：
ACL SETUSER ardm_client on >ardm123 ~cache:* &* +get +set +keys
并在连接窗口填写 username=“ardm_client”, password=“ardm123” —— 实现最小权限原则。

六、架构启示：从 ARDM 故障看现代中间件客户端设计范式

graph LR A[Redis Server] -->|RESP v2/v3| B[Client Capability Matrix] B --> C1[Single AUTH only
e.g. ARDM v1.2.x] B --> C2[Multi-User AUTH
e.g. redis-cli 6.2+] B --> C3[SCRAM-SHA-256
e.g. Lettuce 6.3+] C1 -.-> D[Requires default user or requirepass] C2 --> E[Supports named users via ACL] C3 --> F[Pluggable SASL auth]

该故障本质是客户端能力矩阵与服务端协议扩展不匹配的典型案例。资深工程师应建立“协议能力映射表”意识：每次升级 Redis 或客户端前，必须交叉比对 FEATURES.md、CHANGELOG 与 RFC 文档（如 Redis ACL Spec），而非依赖经验直觉。

七、延伸实践：自动化检测脚本（Shell + redis-cli）

#!/bin/bash
# check_ardm_compatibility.sh
REDIS_HOST=${1:-127.0.0.1}
REDIS_PORT=${2:-6379}
PASSWORD=${3:-""}

echo "[INFO] Testing ARDM compatibility for $REDIS_HOST:$REDIS_PORT..."
if redis-cli -h $REDIS_HOST -p $REDIS_PORT AUTH "$PASSWORD" 2>/dev/null | grep -q "OK"; then
  echo "[PASS] Single-parameter AUTH succeeded"
else
  echo "[FAIL] Single-parameter AUTH failed — check 'default' user status"
  redis-cli -h $REDIS_HOST -p $REDIS_PORT ACL LIST | grep "user default on" || echo "[ALERT] 'default' user is OFF or missing!"
fi

```