runcluvfy.sh卡在verifying user equivalence主因是ssh免密虽能登录但无法执行命令，需检查密钥权限、authorized_keys格式、strictmodes策略、dns解析、/tmp可写性及ulimit限制。
runcluvfy.sh 卡在 verifying user equivalence，基本就是互信没生效，不是配置没做，而是权限或时效出了问题。
检查 grid 用户 SSH 免密是否真能跨节点执行命令
很多人以为跑过 sshUserSetup.sh 就完事了，但实际只验证了“能连上”，没验证“能执行任意命令”。runcluvfy.sh 内部会调用类似 ssh node1 date 和 ssh node2 uptime 的组合操作，只要其中任一失败就卡住。
- 手动模拟：以
grid用户分别在两个节点上执行ssh node1 date、ssh node2 date、ssh node1 hostname、ssh node2 hostname—— 四条都必须不输密码、无提示、有输出 - 常见失败点：
~/.ssh/id_rsa权限不是600；~/.ssh目录权限不是700；authorized_keys被写入了带换行或空格的密钥（比如复制时多粘了个空格） - 注意：如果用了
ssh-agent，必须确保runcluvfy.sh运行时的 shell 环境里 agent 已加载且 key 已ssh-add—— 图形界面启动的 OUI 往往走的是新 shell，不会继承终端里的 agent 状态
确认 SSH 密钥对是否被系统策略拒绝
RHEL/CentOS 7+ 默认启用 StrictModes yes，且某些安全加固策略会禁用 ~/.ssh/authorized_keys 中的某些选项（如 no-port-forwarding 或环境变量设置），导致虽能登录，但被拒绝执行远程命令。
- 检查
/etc/ssh/sshd_config中的StrictModes是否为yes（默认是），然后确认grid用户家目录、.ssh目录、id_rsa、authorized_keys所有者都是grid:oinstall，且权限严格符合要求 - 临时测试：在任一节点上以
root执行sshd -T | grep -i "strictmodes\|permitchain"，确认无非预期限制 - 关键信号：如果
ssh node1 date返回Permission denied (publickey)，但ssh node1能进 shell，说明服务端拒绝了非交互式命令 —— 很可能是authorized_keys里某行开头加了command=...或其他限制项，删掉再试
排查 SSH 连接超时与连接复用失效
runcluvfy.sh 并发探测多个节点，若某节点 SSH 响应慢（比如 DNS 反查失败、TCP 连接卡顿），它不会报错，而是静默等待直到超时（默认约 60 秒），表现就是“挂起”。
- 在每个节点执行
ssh -o ConnectTimeout=5 -o BatchMode=yes grid@node1 date，看是否秒回；若超时，检查/etc/ssh/sshd_config是否设了UseDNS no（必须设） - 检查
/etc/hosts中所有节点名（包括自身）是否都能正向+反向解析；hostname -f输出必须和/etc/hosts中 public IP 对应的 FQDN 完全一致 - 避免使用连接复用（
ControlMaster）配置 ——runcluvfy.sh不识别，反而可能因 socket 文件权限问题阻塞
真正容易被忽略的是：即使所有节点间 ssh 都通，runcluvfy.sh 仍可能因某个节点的 /tmp 不可写、或 grid 用户的 ulimit -n 过低（低于 65536）而卡在等效性检查阶段 —— 它不会告诉你具体哪一步失败，只停在那个步骤。所以别只盯着 SSH，先跑一遍前提条件校验清单。
