Oracle RAC跨节点操作使用内嵌JSch或自封装SSH层，绕过系统ssh配置；INS-06006本质是scp输出含警告导致Java解析失败；需禁用StrictHostKeyChecking、用rsa-2048密钥、完成四类互信，并可用-T wrapper临时修复。
Oracle RAC内部SSH调用不走系统默认流程
Oracle RAC 的集群管理工具（如 crsctl、srvctl、cluvfy）在执行跨节点操作时，并非简单调用系统 ssh 命令，而是通过内嵌的 Java SSH 库（JSch）或自封装的 SSH 封装层发起连接。这个封装层会绕过用户 shell 环境、~/.ssh/config、甚至部分 OpenSSH 客户端参数，直接构造连接请求并解析输出。一旦密钥格式、算法协商、SCP 输出格式或权限控制不符合其硬编码预期，就会静默失败——你手工 ssh db02 date 成功，不代表 srvctl start database -d orcl 能成功触发远程启动。
INS-06006 报错本质是 scp 输出解析失败
Oracle 安装器和部分运维命令（尤其是 cluvfy comp ssh 或 OUI 的 Test 按钮）实际检测的是 scp 文件传输连通性，而非单纯 ssh 登录。OpenSSH 8.x 默认启用了 -T（禁用伪终端）和更严格的输出格式，导致 scp 在传输成功后多打印一行类似 Warning: Permanently added 'db02' (RSA) to the list of known hosts. 的提示。Oracle 的 Java 解析逻辑只认旧版 OpenSSH 7.x 那种“纯数据流无额外日志”的输出，一见到非预期字符串就判定为“命令执行失败”，直接抛出 [INS-06006]。
最容易被忽略的三个配置点
-
~/.ssh/config中任何Host *或StrictHostKeyChecking no都会导致cluvfy报PRVF-7532并中止检查，哪怕密钥本身完全正确 - 私钥必须是
rsa-2048：OpenSSH 8.x 默认生成ed25519，而 Oracle GI 19c 完全不识别该类型，ssh-copy-id会静默跳过 - 所有节点都必须完成
ssh db01、ssh db02、ssh $(hostname)、ssh localhost四种组合的互信，缺一不可——OUI 会逐个尝试这些目标主机名
/usr/bin/scp 替换是最稳的临时解法
不是修 SSH，而是让 Oracle 调用的 scp 行为回归 OpenSSH 7.x 的语义：
sudo mv /usr/bin/scp /usr/bin/scp.orig sudo tee /usr/bin/scp <p>这个 wrapper 强制关闭伪终端，屏蔽警告输出，骗过 Oracle 的解析器。但要注意：必须在所有节点执行；安装完成后务必恢复原 <code>scp</code>，否则会影响 Ansible、rsync 等依赖标准 <code>scp</code> 行为的工具。</p><p> 真正卡住人的从来不是“怎么配密钥”，而是 Oracle 对 SSH 生态的封闭式假设——它不信任你的 OpenSSH 配置，也不兼容新协议特性，只认自己测试过的那套“老规矩”。</p>
