CHAP认证在targetcli中必须配置incoming和outgoing两层凭据，缺一不可；incoming用于target验证initiator，outgoing用于initiator验证target，二者用户名密码须不同且需在服务端ACL下分别设置，客户端对应配置username/password与username_in/password_in。
targetcli 里 CHAP 认证必须配两层，缺一不可
单向 CHAP（只验证客户端）在 targetcli 里默认不生效，因为 LIO 内核模块要求：只要启用了 CHAP，就必须同时配置 incoming（客户端向服务端提交的凭据）和 outgoing（服务端向客户端提交的凭据）。否则客户端执行 iscsiadm -m node -T <iqn> --login 会卡住或报 initiator reported error (02/01)。
关键点在于：这两组凭据不是“服务端一份、客户端一份”，而是服务端既要存自己的 outgoing 密码（供客户端验证自己），也要存客户端的 incoming 密码（用于验证客户端）；客户端则要存服务端的 outgoing 用户名密码（即它眼中的 in 凭据）。
-
incoming是 initiator 主动提供的，target 用它来验 initiator 身份 -
outgoing是 target 主动提供的，initiator 用它来验 target 身份 - 两组用户名密码必须不同，且不能明文写在配置里——
targetcli会自动哈希后存进 node DB
在 targetcli 交互界面里配 CHAP 的实操步骤
进入 targetcli 后，先定位到具体 TPG（比如 /iscsi/iqn.2026-10.example:storage/tpg1），再按顺序执行：
- 启用认证：
set attribute authentication=1（关闭 auto-auth） - 设置 ACL 下的 incoming 凭据：
acls/create iqn.1994-05.com.redhat:client1→ 进入该 ACL 目录 →set auth username=client1 password=secret123 - 设置同一 ACL 下的 outgoing 凭据：
set auth mutual_username=target1 mutual_password=secret456 - 确认 portal 开放且未被 ACL 拦截：
portals/create 10.1.8.102 3260（别留着默认0.0.0.0） - 最后
saveconfig持久化，否则重启 target 服务后丢失
注意：mutual_username 和 mutual_password 是 target 端生成并“告诉”客户端的凭据，不是客户端自己设的。客户端配置时要用这两个值填入自己的 iscsid.conf 或 node 配置项。
客户端 iscsiadm 怎么对应服务端的 CHAP 设置
服务端配了双向 CHAP，客户端就绝不能只配 username/password。必须显式开启 mutual 认证，并填对两组凭据：
- 编辑
/var/lib/iscsi/nodes/<iqn>/<portal>,3260,1/default - 把
node.session.auth.authmethod = CHAP改为CHAP（不是None） - 填入
node.session.auth.username = client1和node.session.auth.password = secret123（对应服务端incoming） - 填入
node.session.auth.username_in = target1和node.session.auth.password_in = secret456（对应服务端outgoing） - 改完后运行
iscsiadm -m node -T <iqn> -p 10.1.8.102 --op update刷新配置
漏掉 _in 后缀那两项，或者用户名写反（比如把 target1 当成客户端用户名），登录就会失败，且错误日志里通常只显示 login failed，不会说明是哪边没对上。
为什么配完还是被拒？重点检查这三处
CHAP 登录失败最常卡在这三个地方，而不是密码本身错：
- 服务端 firewall 没放开
3260端口，或客户端连的是 NAT 后的地址但服务端 portal 绑定的是内网 IP -
targetcli里 ACL 名称（IQN）和服务端iscsid.conf中的node.session.auth.username不一致，比如多空格、大小写、短横线位置不对 - 客户端执行
iscsiadm -m discovery -t st -p 10.1.8.102时没加-l参数，导致 discovery 阶段没触发认证，但 login 阶段又因 ACL 拒绝而失败
真正容易被忽略的是：CHAP 在 discovery 阶段（SendTargets）和 session 阶段（Login）是分开控制的。服务端若只开了 session 认证，但 discovery 阶段没设 discovery_auth，客户端发现不到 target；若 discovery 开了但 session 没开，客户端能发现却登不上。两者必须匹配。
