先交代一下环境Oracle Linux 8.3两个节点装的是 Oracle 19c RACGrid 和 Database 都是 19c。前面所有环境准备都做完了结果在 OUIOracle Universal Installer的 SSH Connectivity 这一步卡死了输入 oracle 密码点 Test等了十几秒直接弹一个红色错误 INS-06006。查日志就一句话scp failed。更要命的是你手动 ssh 到对端节点完全正常authorized_keys 权限也检查过防火墙也关了SELinux 也放了但 OUI 就是过不去。当时我第一反应是去 MOS 找补丁翻了一圈发现这个场景下打补丁不一定是最优先的解。后来用了一个临时替换 scp 的骚操作五分钟解决问题安装顺利完成。今天把整个过程拆开讲清楚INS-06006 到底在报什么为什么不建议一上来就打补丁以及这个替换 scp 的方案怎么落地、怎么恢复、有哪些坑。这篇文章适合正在 Linux 8.x 上部署 19c RAC、卡在 SSH 互信校验的同学也适合被 OpenSSH 和 Oracle 安装器兼容性问题折腾过的人。既然点进来了说明你也遇到类似问题了直接往下看。1. INS-06006 卡住时你看到的到底是个什么错误1.1 错误弹出的准确位置INS-06006 不是在 Grid 安装一开始就出现的它出现在安装向导中间的“SSH Connectivity”页面。这个页面的作用是让 OUI 自动帮你配置各节点之间的 ssh 互信或者在你已经手动配置好互信的情况下做一次连通性校验。这个页面长什么样你输入节点列表之后OUI 会要求你提供一个操作系统的登录密码然后点 Test。它会尝试从当前节点去连接其他节点并在所有节点之间同步公钥。如果这一过程任何一步失败OUI 就会直接报错错误代码就是 INS-06006。常见的完整报错文案大概是这样的INS-06006: Passwordless SSH connectivity is not set up between the following node(s): rac1, rac2注意这里有个容易让人误判的地方错误里写的是“passwordless SSH connectivity is not set up”但实际手动测试的时候你用ssh rac2 date完全不需要密码说明互信本身是通的。所以很多人会卡在这里非常困惑——手动是好的自动化就是不行。问题不出在互信而出在 OUI 调用 scp 这个具体动作上。1.2 installActions 日志里的蛛丝马迹遇到这种报错第一件事不是猜而是翻安装日志。Grid 安装日志一般在这几个位置/u01/app/oraInventory/logs/installActions*.log/u01/app/oraInventory/logs/oraInstall*.log如果替换过 Inventory 路径就到你自定义的 oraInventory 目录下找用tail -50看报错时间点附近的日志你大概率能看到类似这样的记录Info: - scp failed on node rac2 Info: - ssh failed on node rac2 SEVERE: - OFA-00000日志中通常还会记录到具体的 scp 命令行。我这次的情况是 OUI 调用了 scp 去把本机的authorized_keys追加到另一台的~/.ssh/authorized_keys这个动作失败返回了非零状态码于是 OUI 立刻判定互信配置失败。注意OUI 的判定逻辑很简单只要 scp 的退出码不是 0就认为失败。至于 scp 为什么失败它不关心细节只给你一个笼统的 INS-06006。1.3 为什么偏偏是 Linux 8.3 容易中招Linux 8.3 自带的 OpenSSH 是 8.0p1 这一版。这个版本相比 RHEL 7 时代的 OpenSSH 7.x对加密算法、密钥交换算法、主机密钥类型的检查严格了很多同时 scp 在非交互环境下的行为也更敏感。Oracle 19c 的 OUI 是一个 Java 程序它执行 scp 的时候不会像人一样去响应密码提示也不会处理各种警告信息。只要 scp 在远端执行时碰到任何它意料之外的情况比如算法协商告警、known_hosts 不匹配、authorized_keys 权限有问题、SSH 握手时输出了一段提示它都可能直接失败然后把失败状态返回给 OUI。还有一个隐藏因素RHEL 8 系列引入了系统级 crypto policy/etc/crypto-policies/back-ends/openssh.config会全局影响 ssh 和 scp 的算法协商。Oracle 安装器内置的某些旧调用方式遇到系统禁用某些老算法时也会出现“手动执行没问题自动化执行就失败”的现象。所以这个问题的本质不是你的互信没有配好而是 scp 这个中转命令在受限环境里没能按 Oracle 期望的方式跑完。2. 先别急着补丁把场景拆透再动手2.1 手动 ssh 通不等于互信校验能过这是很多人最容易忽略的一点。ssh 能免密登录说明公钥认证链路是通的。但 OUI 的校验链路比单纯 ssh 登录多了一步——它要调用 scp 往远端写文件或者执行一个远端命令来回传文件。这就有几个新的检查点scp 使用的认证方式是否和 ssh 一致远端目录是否存在且可写远端目标文件的属主和权限是否正确sshd_config 里是否启用了允许 scp 工作所需的通道我这次遇到的问题就是手动 ssh 能通但 scp 在非交互调用时报错。这也是最典型的“表面现象良好、实际链路不通”的场景。所以排查顺序应该是ssh 能通不代表 scp 能通scp 能通不代表 OUI 能通。一层一层往上排。2.2 补丁为什么不是第一选择MOS 上确实能搜到不少针对 INS-06006 的补丁类建议也有人在社区里说“打上某个 PSU 就好了”。但以我实际经验来看安装阶段补丁不是最优解原因有三点。第一补丁版本匹配很麻烦。你装的是 19.16补丁可能是针对 19.3 或者 19.10 的装错了轻则无效重则影响其他功能。Oracle 的补丁体系是有严格的版本前提的验证补丁依赖的时间成本有时候比解决问题本身还高。第二补丁的操作不可逆。补丁打下去之后如果不符合预期回滚又是一套流程。在一个本来已经很干净的安装环境里因为一个互信校验问题去改动软件版本风险收益比不划算。第三这个问题的根源往往不在 Oracle 软件而在操作系统层面。你打了数据库补丁系统里 OpenSSH 的行为没变那下次再遇到类似调用场景可能还会触发同样的问题。补丁是兜底手段不该是第一选择。2.3 这个替换方案的真实边界临时替换 scp 这个操作本质上是一个“欺骗 OUI 校验”的手段。它不是在根治 ssh 和 scp 的底层问题只是让安装程序在互信校验这一步能够顺利通过。所以它有一个非常明确的前提你的手动互信必须是真实有效的。也就是说oracle 用户和 root 用户到所有节点的免密 ssh都必须已经手动打通了。替换 scp 只是让 OUI 在“把 authorized_keys 再传一遍”的时候不去计较这次传的是否真的成功因为反正你已经手动做完了。如果手动互信本来就没做你用这个方案骗过了 OUI那后续安装大概率会在更深的阶段翻车比如 root.sh 执行失败、集群无法启动、vipca 报错等等。到时候排查起来比 INS-06006 本身痛苦得多。这个边界一定要写清楚。3. 临时替换 scp 的骚操作完整实操流程3.1 前提条件检查在动手替换 scp 之前先花两分钟确认这几项oracle 用户从 node1 到 node2、从 node2 到 node1 都能免密 sshroot 用户从 node1 到 node2、从 node2 到 node1 都能免密 ssh所有节点的/etc/hosts里节点短名和完整域名解析一致两个节点的系统时间基本一致否则 ssh 认证也可能出问题确认完这些才进入替身脚本的制作环节。3.2 备份原始 scp 程序先看 scp 在哪、是什么包which scp rpm -qf /usr/bin/scp正常情况返回的是openssh-clients。然后备份原文件cp -a /usr/bin/scp /usr/bin/scp.orig注意用cp -a保留原始属性别用普通的cp。备份完之后顺手确认一下 scp.orig 能不能正常执行/usr/bin/scp.orig正常会打印 scp 的用法说明这说明备份可用。3.3 编写临时替身 scp 脚本替身脚本的逻辑是这样先尝试执行原始 scp如果执行成功那就什么都不管返回成功如果执行失败再看命令行参数里是不是包含authorized_keys这个关键词。如果是说明这是在同步互信文件而手动互信已经配好了所以直接返回 0让 OUI 认为成功。如果不是则返回原始 scp 的错误码避免掩盖其他问题。创建脚本/tmp/install_tools/scp_wrapper.sh内容如下#!/bin/bash # 临时替身规避 OUI SSH互信校验阶段的scp失败 # 逻辑真实scp失败时如果传输目标是authorized_keys强制返回成功 LOG/tmp/scp_wrapper.log TS$(date %Y-%m-%d %H:%M:%S) echo [$TS] called: $0 $* $LOG /usr/bin/scp.orig $ $LOG 21 RC$? echo [$TS] original scp exit code: $RC $LOG if [ $RC -ne 0 ]; then case $* in *authorized_keys*) echo [$TS] authorized_keys copy failed but pre-configured, force success $LOG exit 0 ;; esac fi exit $RC然后给脚本加执行权限并替换到系统路径chmod 755 /tmp/install_tools/scp_wrapper.sh cp /tmp/install_tools/scp_wrapper.sh /usr/bin/scp如果提示/usr/bin/scp是二进制文件、被占用可以先删掉再放rm -f /usr/bin/scp cp /tmp/install_tools/scp_wrapper.sh /usr/bin/scp chmod 755 /usr/bin/scp这一步做完当前节点的 scp 已经被替换成替身脚本了。执行一下scp你会看到没有任何输出因为脚本走了原 scp 的调用原 scp 没有参数时会打印帮助并返回错误码但日志里会记录下来。3.4 两个节点都替换并验证记得所有节点都要做同样操作。OUI 的互信校验可能会从任一节点发起如果你只替换了 node1 的 scpnode2 上的 scp 仍可能被远程调用到时候还是会失败。在 node1 和 node2 上分别执行上面的备份、写脚本、替换三步。替换完成后做几个基本验证先测试普通文件传输是否仍正常scp /etc/hosts node2:/tmp/scp_test.tmp这个命令走的是替身脚本脚本会调用原 scp 真正执行传输所以文件应该正常传过去。再模拟一下失败场景看替身脚本是否按预期处理。比如在本地创建一个不存在的源文件目标是 authorized_keysscp /tmp/not_exist_file node2:/home/oracle/.ssh/authorized_keys这个命令正常情况下应该失败但因命令行参数里包含authorized_keys替身脚本会强制返回 0。你可以接着执行echo $?会看到返回 0。同时查看日志cat /tmp/scp_wrapper.log里面应该记录了原始 scp 的失败以及“force success”的标记。这就说明脚本逻辑正常。3.5 OUI 重新测试与安装推进替身脚本就位后回到 OUI 的 SSH Connectivity 页面重新填入 oracle 密码再点 Test。这一次OUI 在执行 scp 同步 authorized_keys 时哪怕原 scp 因为某些原因失败替身脚本也会返回成功互信校验就能通过。只要手动互信是真的配好的这步之后安装流程就能正常往下走。通过之后别急着把所有节点都停留在替身状态继续安装。我的习惯是Grid 软件安装到 root.sh 执行完、集群起来之后立刻恢复 scp。因为这个替身脚本只是临时方案长期存在可能影响后续其他管理操作。3.6 安装完成后恢复 scp恢复操作很简单在全部节点上执行rm -f /usr/bin/scp mv /usr/bin/scp.orig /usr/bin/scp然后确认恢复结果ls -l /usr/bin/scp /usr/bin/scp如果你忘了备份原文件也可以用 yum 重新安装 openssh-clients 来恢复yum reinstall -y openssh-clients但这种方法不如备份恢复干净建议还是动手前做好备份。恢复之后再检查一下/tmp/scp_wrapper.log确认在整个安装周期里这个替身脚本到底被调用过多少次、是否出现过非 authorized_keys 的错误。如果发现有非互信场景的错误最好复盘一下原因看看是不是有其他东西也在依赖 scp。4. Linux 8.3 装 19c RAC安装前这些坑要提前排掉4.1 系统参数和依赖包准备先别急着吐槽 INS-06006很多时候互信问题只是表面现象前面一堆环境问题没有收拾干净后面迟早会爆。Linux 8.3 上装 19c RAC有几个基础项必须提前做好。依赖包方面Oracle Linux 8 可以直接装预安装 RPM一步到位dnf install -y oracle-database-preinstall-19c如果不是 Oracle Linux是 CentOS 8.3 或者 RHEL 8.3那就手动把这些包装上bc, binutils, gcc, gcc-c, glibc, glibc-devel, ksh, libaio, libaio-devel, libstdc, libstdc-devel, libX11, libXau, libXi, libXtst, libXrender, make, net-tools, nfs-utils, python3, python3-configshell, python3-rtslib, python3-six, smartmontools, sysstat, targetcli, time, wget。用户和组 19c 不再用默认的 54321 那一套其实还是建议按照安装文档统一建groupadd -g 54321 oinstall groupadd -g 54322 dba groupadd -g 54323 oper groupadd -g 54324 backupdba groupadd -g 54325 dgdba groupadd -g 54326 kmdba groupadd -g 54327 asmdba groupadd -g 54328 asmoper groupadd -g 54329 asmadmin useradd -u 54321 -g oinstall -G dba,oper,backupdba,dgdba,kmdba,asmdba,asmoper,asmadmin oracle useradd -u 54322 -g oinstall -G asmdba,asmoper,asmadmin grid目录布局mkdir -p /u01/app/19c/grid mkdir -p /u01/app/oracle chown -R grid:oinstall /u01/app/19c chown -R oracle:oinstall /u01/app/oracle chmod -R 775 /u01/app/19c内核参数写在/etc/sysctl.d/99-oracle.conffs.file-max6815744 kernel.sem250 32000 100 128 kernel.shmmni4096 kernel.shmall1073741824 kernel.shmmax4398046511104 net.core.rmem_default262144 net.core.rmem_max4194304 net.core.wmem_default262144 net.core.wmem_max4194304 fs.aio-max-nr1048576 net.ipv4.ip_local_port_range9000 65500最后sysctl --system生效。注意shmmax和shmall要根据服务器内存调整公式是先看物理内存多大shmmax 设为物理内存的一半以上是比较稳妥的。资源限制写在/etc/security/limits.d/99-oracle.conforacle soft nofile 1024 oracle hard nofile 65536 oracle soft nproc 2047 oracle hard nproc 16384 oracle soft stack 10240 oracle hard stack 32768 oracle soft memlock 3145728 oracle hard memlock 3145728 grid soft nofile 1024 grid hard nofile 65536 grid soft nproc 2047 grid hard nproc 16384 grid soft stack 10240 grid hard stack 32768 grid soft memlock 3145728 grid hard memlock 3145728这些基础项不做好后面遇到什么奇奇怪怪的问题都没法定位。4.2 hosts、防火墙与 SELinux互信出问题很多都出在 hosts 和防火墙配置上。Linux 8.3 默认的防火墙规则和 SELinux 策略对 Oracle RAC 的节点间通信影响很大。hosts 文件里必须保证节点短名和完整域名都有条目并且解析一致。比如192.168.1.10 rac1 rac1.localdomain 192.168.1.11 rac2 rac2.localdomain 192.168.1.12 rac1-vip rac1-vip.localdomain 192.168.1.13 rac2-vip rac2-vip.localdomain 192.168.1.20 rac1-priv rac1-priv.localdomain 192.168.1.21 rac2-priv rac2-priv.localdomain避免在 hosts 里把主机名解析成 127.0.0.1 或者 localhost否则 ssh 连接时主机密钥校验会乱掉。防火墙方面最简单的方法是初始化阶段先停掉systemctl stop firewalld systemctl disable firewalldSELinux 如果不想彻底关至少先改成 permissivesed -i s/SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config setenforce 0这两个操作在正式生产环境要谨慎评估但安装 RAC 的场景下先把安装跑通再慢慢加固是经验之谈。4.3 手动配置双向互信的标准姿势前面反复强调替身 scp 的前提是手动互信已经配好。这里给出手动互信的完整流程两条节点都要做。在 node1 上以 oracle 用户执行ssh-keygen -t rsa -b 4096 -N -f ~/.ssh/id_rsa然后复制公钥到 node2ssh-copy-id -i ~/.ssh/id_rsa.pub oraclenode2这个过程会要求输入一次 node2 的 oracle 密码输入即可。然后在 node1 上测试ssh node2 hostname ssh node2 date能免密返回就算通。接着在 node2 上重复同样操作把 node2 的公钥复制到 node1ssh-keygen -t rsa -b 4096 -N -f ~/.ssh/id_rsa ssh-copy-id -i ~/.ssh/id_rsa.pub oraclenode1root 用户也一样来一遍。注意 root 用户要分别登录两个节点执行 ssh-keygen 和 ssh-copy-id不能只在一个节点上做。配好之后检查权限ls -ld ~/.ssh ls -l ~/.ssh/authorized_keys.ssh目录权限应该是 700authorized_keys文件权限应该是 600。权限不对ssh 会直接拒绝使用这个公钥文件这也是 INS-06006 的常见诱因之一。5. 常见问题与排查技巧实录5.1 替换了 scp 还是报 INS-06006 怎么办这种情况我遇到过最常见的原因是只替换了当前节点没替换远端节点。OUI 的互信校验不是单向的本地和远端都要调用 scp任何一端失败都会报错。所以替换一定要所有节点全部执行。还有一种情况替换之后没有刷新 OUI。有些安装界面会缓存之前失败的状态直接重新执行 Test 不一定触发新的流程。稳妥的做法是点 Back 退出当前页面再重新进入 SSH Connectivity 页面或者干脆重新启动一次 runInstaller。再有就是替身脚本本身没生效。确认一下/usr/bin/scp是不是已经被正确覆盖file /usr/bin/scp正常应该显示 “POSIX shell script” 而不是 ELF 二进制。5.2 卡在 Host key verification failed这个问题和互信的关系不太直接但经常和 INS-06006 一起出现。如果日志里看到host key verification failed说明 known_hosts 里没有对端主机的指纹或者指纹已经变了。原因是节点系统重装过、或者主机密钥重新生成过。解决办法是登录到 node1清理掉 node2 的旧条目ssh-keygen -R node2 ssh-keygen -R 192.168.1.11然后重新连接一次接受新指纹ssh node2 hostname反过来在 node2 上也要处理 node1 的旧条目。5.3 Permission denied (publickey,password)日志里出现这个说明公钥认证没成功退回了密码认证而密码认证在非交互环境下是走不通的。优先查三样东西当前用户的~/.ssh/authorized_keys里是否真的包含了其他节点的公钥~/.ssh目录属主是否当前用户sshd 是否允许该用户使用公钥认证/etc/ssh/sshd_config 里PubkeyAuthentication必须为 yes。如果之前有人为了安全把它注释掉也会导致这个问题。5.4 Grid 安装后续阶段的 ssh 相关报错有时候 INS-06006 过了但后面 root.sh 或者 vipca 阶段又出现类似 ssh 的问题这时候别慌大概率还是节点互信问题没彻底解决。比如 root.sh 执行时会以 root 用户去连接其他节点如果你的 root 互信没配好就会在配置集群的几个阶段报错。解决办法是回根因不是去替换 root 用户的 scp而是把 root 到各节点的免密配置重新检查一遍。替身脚本可以帮你渡过 OUI 的校验但救不了真实互信缺失的问题。我把这次排查中用到的信息做成了一张速查表方便以后直接对照现象可能原因处理办法OUI 测试卡住日志中 scp 挂起scp 等待密码输入确认手动互信已建立或临时替换 scpHost key verification failedknown_hosts 不匹配用 ssh-keygen -R 清理后重新连接Permission denied (publickey,password)公钥未同步或权限不对重跑 ssh-copy-id检查 .ssh 与 authorized_keys 权限替换 scp 后仍然报 INS-06006只替换了单节点所有节点执行相同替换操作各节点都已配置仍失败hosts 解析不一致或防火墙拦截统一 hosts、关闭或放行节点间端口root.sh 执行阶段 ssh 类报错root 用户互信未配置单测 root 到各节点的免密登录最后再分享一个小技巧替身脚本里的日志/tmp/scp_wrapper.log别急着删。安装完全跑通之后看一眼这个日志你能清楚地看到 OUI 在互信校验阶段到底调了什么命令、传了什么文件、哪个节点失败了。这个日志比 installActions 还要直观对复盘整个安装过程非常有帮助。我个人在实际操作中的体会是这个问题本身并不复杂但特别容易把人带偏。一心想着打补丁反而会绕很远的路。遇到 INS-06006先分清楚“真实互信是否有效”和“scp 这个命令是否满足 Oracle 的调用方式”这两件事再决定用临时替换还是彻底排查。临时替换这个方案越早用越省事但也要清楚地知道它只是一个过渡手段不是最终答案。