iDRAC 网页能登录，ipmitool 却认证失败：一次原密码重写修复

先区分宿主机与 BMC#

本文用下面的对应关系表示现场：

远程查询使用 BMC 地址：

1
# 示例地址，执行前替换成自己的 BMC 地址。
2
BMC_IP=192.0.2.13
3
ipmitool -I lanplus -H "$BMC_IP" -U root -a power status

这里用 -a 交互输入密码，文章不保留现场的明文密码参数。ipmitool 的手册说明了该选项，也不建议把密码直接作为命令行参数传入。ipmitool 手册

后面出现的 -I open 则是访问命令所在宿主机的本地 BMC 接口。它不通过 -H 指定远程地址，因此修复时必须先确认自己登录的是哪台服务器。

网络和本机 IPMI 都正常#

首先在 node-a 上检查版本、设备和到 BMC 的连通性：

1
hostname
2
ipmitool -V
3
ls /dev/ipmi*
4
ip route get "$BMC_IP"
5
ping -c 2 -W 2 "$BMC_IP"
6

7
# 本次用于判断 HTTPS 服务是否响应，不作为证书可信性验证。
8
curl -k -I --connect-timeout 4 --max-time 8 "https://$BMC_IP/"

现场可以看到 /dev/ipmi0，Ping 两次均成功，HTTPS 返回了指向 iDRAC 起始页面的 302。

这些结果说明基础连通性与 HTTPS 服务有响应，但还不能证明远程 IPMI 能建立会话。接着通过本机接口查询：

1
sudo ipmitool -I open mc info
2
sudo ipmitool -I open chassis power status

电源状态返回：

1
Chassis Power is on

本机能读到控制器信息和电源状态，说明 BMC 并非完全失去响应。故障范围开始收敛到远程访问路径。

排查中还尝试过 Redfish HTTPS 查询：一次带认证的请求超时，另一次无认证请求返回 401。这两次结果没有证明 Redfish 认证可用，也不足以解释 IPMI 的失败，后续没有据此修改 Redfish 或 Web 服务配置。

详细错误把范围缩小到认证交换#

为原查询增加一次详细输出：

1
ipmitool -I lanplus -H "$BMC_IP" -U root \
2
  -a -N 2 -R 1 -v power status

关键输出是：

1
Using best available cipher suite 17
2

3
> RAKP 2 HMAC is invalid
4
Error: Unable to establish IPMI v2 / RMCP+ session

与最初只有“无法建立会话”相比，这里已经进入了 RAKP 认证交换。客户端收到认证响应，却没有通过 HMAC 校验。排查重点因此转向凭据、账户认证状态以及协议兼容性，而不是继续把所有原因都归到网络不通。

我也显式测试了套件 3：

1
ipmitool -I lanplus -H "$BMC_IP" -U root \
2
  -a -C 3 -L ADMINISTRATOR -N 2 -R 1 -v power status

第一次尝试曾返回 insufficient resources for session；随后本机查询显示活动 IPMI 会话为 0，间隔后重试，套件 3 同样报 RAKP 2 HMAC is invalid。没有仅凭那一次资源错误，就认定 BMC 会话长期耗尽并重启控制器。

更换套件没有解决本次问题。 后续修复完成后，默认套件 17 就能正常查询，也没有留下强制 -C 3 的配置。

同一密码能登录 SSH，IPMI 权限也已启用#

当时已确认，同一组凭据可以登录 iDRAC 网页。随后又使用这组凭据登录了 BMC 的 SSH，并读取配置：

1
racadm get iDRAC.IPMILan.Enable
2
racadm get iDRAC.IPMILan.PrivLimit
3
racadm get iDRAC.Users.2.IpmiLanPrivilege
4
racadm get iDRAC.Users.2.Enable
5
racadm getversion

同时，在宿主机上读取 IPMI 通道与用户信息：

1
sudo ipmitool -I open channel info 1
2
sudo ipmitool -I open user list 1
3
sudo ipmitool -I open channel getaccess 1 2

这些编号来自本次现场查询：通道 1 是 LAN 通道，用户 2 是 root。其他机器应先核对映射，不能直接套用编号。

此时，“密码整体无效”“账户禁用”“没有开启 IPMI over LAN”都不符合现场证据。但 SSH 登录成功仍然不能替代一次 IPMI 认证成功。

Dell 的 iDRAC8 文档描述过一种相关情形：账户只设置了 SHA256 密码哈希、缺少其他认证所需数据时，IPMI 认证可能不可用。这说明同一账户在不同管理协议上的认证表现确实可能不同。Dell：Using hash passwords for improved security

这是一条排查依据，不是本机根因已经查明。 本次没有读取密码哈希，也没有证据确认此前发生过配置导入、主板更换或特定固件缺陷。能够确认的是：同一凭据的 SSH 登录正常，远程 IPMI 的认证校验持续失败。

唯一的生产写入：重新保存原密码#

因为目标服务器同时承载控制面、业务和存储，我先明确了操作范围：只重新保存这个 BMC 账户的当前密码，随后复验；若保存失败就停止。获得授权后，又采集了 Kubernetes、etcd、Ceph 和 Pod 的基线。

写入前，三节点 Ready、API /readyz 通过、etcd 三个端点健康；Ceph 为 HEALTH_OK，18 个 OSD 全部 up/in。已有的业务非就绪项单独保留，没有把它算作本次 BMC 故障的结果。

确认登录到 node-a、用户 ID 2 对应 BMC 的 root 后，执行：

1
# 生产写入：仅适用于已核实的目标宿主机和 BMC 用户 ID。
2
# 此处修改的是 BMC 账户，不是 Linux 的 root 密码。
3
sudo ipmitool -I open user set password 2

命令要求输入两次密码。两次都通过隐藏输入提供原来的密码内容，返回：

1
Set User Password command successful (user 2)

这就是本次唯一的生产配置写入。没有修改通道权限、网络、固件或其他用户，也没有重置、重启 iDRAC，或者对宿主机执行电源操作。

“密码内容没变”不意味着没有发生写入：这个命令仍然重新设置了 BMC 中该用户的密码。之后认证恢复，支持账户认证状态异常这一判断；但没有检查 BMC 内部存储，不能进一步声称某个具体哈希字段已被证明损坏。

这一步也不应成为看到 RMCP+ 错误就自动执行的通用修复。目标映射、账户编号和其他登录路径都需要先确认；本次具备已验证的原密码、可用的宿主机本地 IPMI 接口和明确授权。

验收覆盖两台客户端与原有业务基线#

首先从 node-a 再次执行默认 lanplus 查询，详细输出确认使用套件 17，最终返回：

1
Chassis Power is on

然后从另一台节点 node-b 发起同样的远程查询，再次成功。这样既验证了本机到 BMC 的远程路径，也覆盖了第二个客户端，而不是只重复读取 /dev/ipmi0。

1
# 分别在 node-a 和 node-b 执行，密码仍交互输入。
2
BMC_IP=192.0.2.13
3
ipmitool -I lanplus -H "$BMC_IP" -U root -a power status

同一密码重新登录 iDRAC SSH 也成功，读取 iDRAC.IPMILan.Enable 仍为 Enabled。修复后没有另行验收网页登录或 Redfish 认证，不把它们写进通过清单。

到 10 月 2 日 00:17，前后检查结果为：

活动 Pod 数量从 320 变成了 319，进一步查询确认是一项 CronJob 正常完成、phase 变成 Succeeded。原有的一项业务非就绪及其 284 次重启计数保持；Ceph 原有三项 AUTH 告警静默也保持。这次验收没有把既有异常描述为已经解决。

整个过程只验证了远程会话认证和只读电源查询，没有执行实际关机、启动、重启或电源循环，也没有证明 BMC 在业务网络完全中断时仍有独立可用的管理通道。

这次留下的日常检查命令仍然是最开始那一条：

1
ipmitool -I lanplus -H "$BMC_IP" -U root -a power status

网页登录成功、本机 IPMI 可用、远程 IPMI 会话成功，是三项各有边界的检查。把它们逐项核对后，才有依据把修改范围收窄到一个 BMC 账户，并用原来的查询路径确认恢复。