先说结论在Linux 8.3上装Oracle 19c RACGrid Infrastructure跑到ssh互信检查时卡住报INS-06006这个报错本身不一定是OpenSSH的锅但确实是OpenSSH版本越新越容易踩的坑。我那次是在客户内网环境不能随便打OS补丁、不能改sshd_config、防火墙策略也动不了前后折腾了一个多小时最后用一个“偷梁换柱”的思路把scp的调用临时包装了一层直接绕过OUI的检测逻辑装完以后再把文件恢复原样。这篇文章就把整个排查过程、原理和操作步骤完整写出来给同样卡在这关的人一个参考。如果你也是DBA、运维或者正在搭RAC环境的新手这篇文章适合你。我会先讲清楚INS-06006到底在检查什么、为什么Linux 8.3上容易翻车再给常规排查路线然后重点拆解“临时替换scp”这个偏方怎么落地以及装完以后怎么回滚——这个方案有风险不能在生产环境留后门所以每一处权限、恢复命令我都会写得非常细。1. 先把INS-06006讲明白OUI到底在检查什么1.1 错误日志去哪找安装Oracle 19c RAC时Grid Infrastructure的图形界面gridSetup.sh在“SSH connectivity”这一步有个自动化功能输入两遍密码OUI会自动把各节点的密钥分发好、建立互信。如果这个自动过程失败了界面就弹出INS-06006字面意思是“Passwordless SSH connectivity is not established between the following node(s)”中文就是节点之间没有建立无密码ssh连接。这个报错出现后大部分人第一反应是手动去配ssh互信配完重试还是报错就开始怀疑人生。其实解决问题的第一步不是反复重试而是先找到OUI的详细日志。我建议按下面顺序找# 1. 安装日志所在目录 $ORACLE_BASE/cvutrace/ $INVENTORY/logs/ # 2. 关键文件通常是这些 installActions*.log installProfile*.log oui*.log实际操作中$INVENTORY/logs/installActions2025-xx-xx.log里会有最完整的错误上下文。用grep直接搜关键字grep -i INS-06006\|ssh\|scp\|exit code installActions2025-xx-xx.log日志里能看到OUI执行了哪个命令、命令的退出码、stderr输出。很多时候报错根因就藏在最后几行里比看界面上的错误提示有用得多。1.2 OUI验证ssh互信的三个步骤OUI自动设置互信时内部动作大致分三步第一步在本节点生成RSA密钥对命令类似ssh-keygen -t rsa -b 2048 -N -f ~/.ssh/id_rsa。如果密钥文件已经存在它会复用旧的这里常见问题就是历史残留的密钥格式或权限不对。第二步通过scp把本节点的公钥id_rsa.pub复制到目标节点的~/.ssh/authorized_keys或者通过ssh usernode cat ~/.ssh/authorized_keys方式追加。此时需要密码认证OUI会把你填的密码交给ssh/scp工具去用。第三步验证环节最要命。OUI会以ssh -o BatchModeyes usernode command的方式执行远程命令BatchModeyes表示“不进行任何交互认证失败直接退出”。如果前两步建立的互信有问题这里就会返回非零退出码然后界面就炸了。这第三步是理解整件事的关键OUI在验证阶段用的是BatchMode意味着它不希望看到任何交互提示包括host key确认、密码输入、警告信息等等。而在Linux 8.3这种OpenSSH 8.2p1环境下首次ssh到新主机名时默认会提示“Are you sure you want to continue connecting (yes/no)”这个提示在BatchMode下会被直接判死。1.3 Linux 8.3上的隐藏变化RHEL/CentOS 8.3自带的OpenSSH版本是8.2p1和老系统常见的OpenSSH 7.4RHEL 7相比有几个直接影响OUI判断的变化。第一个是host key确认行为没有本质变化但known_hosts的格式和管理方式更敏感了。如果之前用root或其他用户ssh过这些节点known_hosts里可能已经有了旧的主机公钥切换到grid用户或oracle用户时指纹不一致就会报“REMOTE HOST IDENTIFICATION HAS CHANGED”。第二个是scp命令默认仍然走传统的SCP协议但会输出一行deprecation警告大致是“Warning: use of the SCP protocol is deprecated”。这个警告本身不致命但它会混入scp的输出流里。OUI的cvu脚本有时做正则匹配额外输出会干扰判断导致明明文件已经拷过去了还是返回失败。第三个坑藏在系统级安全策略里。Linux 8.x默认开启了系统级crypto-policy某些老算法比如ssh-dss、部分弱MAC算法被默认禁用。如果你手工生成的互信里用了旧算法ssh验证时算法协商就会失败。这类问题在日志里表现为no matching key exchange method found之类的关键字。2. 常规排查先走一遍大部分问题不靠换scp解决2.1 手动验证互信的三板斧遇到INS-06006至少在折腾“替换scp”这种偏方之前下面这三组命令必须跑一遍因为多数报错其实是基础互信没配好。以节点node1和node2为例用安装用户一般是grid在两台机器上分别执行# 1. 重新生成密钥注意备份旧的 ssh-keygen -t rsa -b 2048 -N -f ~/.ssh/id_rsa # 2. 把公钥复制到对方机器包括localhost和主机名 ssh-copy-id -i ~/.ssh/id_rsa.pub node1 ssh-copy-id -i ~/.ssh/id_rsa.pub node2 ssh-copy-id -i ~/.ssh/id_rsa.pub localhost # 3. 逐个验证免密登录 ssh -o BatchModeyes node1 hostname ssh -o BatchModeyes node2 hostname这里有个新手最容易忽略的细节OUI检查的是“双向互信”也就是node1能免密ssh到node2同时node2也要能免密ssh到node1。前者只把node1的公钥放到了node2后者还得把node2的公钥放到node1。我见过不少人只做了一侧就跑去重试安装当然继续报INS-06006。另外互信还要覆盖localhost。Oracle的cvu脚本有时会用ssh localhost做本机检查而很多人只配了主机名的互信localhost被漏掉了。建议直接写个小循环验证for host in localhost $(hostname) node1 node2; do ssh -o BatchModeyes -o ConnectTimeout3 $host hostname done2.2 权限、SELinux与主机名解析的坑互信配完还是失败下一步一定是查.ssh目录权限和属主。OpenSSH对权限有硬性要求权限过宽直接拒绝使用authorized_keys。正确的配置是chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chown -R grid:oinstall ~/.ssh注意点是如果曾经用root给grid装过互信或者手工用root拷贝过authorized_keys文件的owner很可能是root冒号rootsshd直接不认。还有一个在Linux 8.x上特别容易忽略的东西SELinux的file context。即使权限、属主全对如果SELinux的context不对比如authorized_keys是从/tmp复制过来的带了tmp_t标签sshd仍然会拒绝读取。修复命令restorecon -R -v ~/.ssh或者检查SELinux状态getenforce # 输出的如果是Enforcing就得留意context问题主机名解析也是大头。RAC要求/etc/hosts里配置好所有节点的真实内网IP和主机名不能依赖DNS而且主机名要和hostname命令输出一致。很多环境下hostname返回的是短主机名但/etc/hosts里写的是FQDNssh解析后找不到匹配也会导致互信验证失败。稳妥的做法是/etc/hosts同时写上短名和全名192.168.1.11 node1 node1.example.com 192.168.1.12 node2 node2.example.com2.3 日志怎么读区分ssh失败和scp失败如果手动互信三项都通了OUI还是报错那就必须老老实实读日志判断到底是ssh阶段失败还是scp阶段失败。打开installActions日志关注两种典型现场。第一种是ssh阶段失败日志里会出现ssh: connect to host node2 port 22: Connection refused或者Permission denied (publickey,gssapi-keyexch,password)。如果是Connection refused优先去查防火墙和sshd服务状态如果是Permission denied回到互信本身。第二种是scp阶段失败日志里会出现scp: /home/grid/.ssh/authorized_keys: No such file or directory一类的错误。这类错误通常不是scp命令本身的问题而是目标端的.ssh目录不存在或权限不对或者scp的non-interactive模式无法处理host key确认。判断清楚阶段之后再用ssh -vvv和scp -v手动模拟一次OUI的执行命令观察输出里卡在哪一个环节ssh -vvv -o BatchModeyes node2 hostname scp -v ~/.ssh/id_rsa.pub node2:/home/grid/.ssh/test_pub3. 临时替换scp的完整实操3.1 什么时候才值得上这个“偏方”说实话替换系统命令属于风险操作我不建议你在一开始就试。但有一种场景下它确实是最快的解法手动互信已经完全验证通过ssh node1 hostname、ssh node2 hostname、ssh localhost hostname全部免密成功但OUI的自动互信检查依然报INS-06006日志里能看到scp或ssh命令返回非零退出码但你手动跑同样的命令却一切正常。我当时面对的情况就是这样客户环境限制多不能重装openssh不能改sshd_config不允许停防火墙也不允许随便打OS补丁。OUI每次都在scp阶段返回失败日志里只有一个模糊的scp exited with code 1而手动执行scp就是成功的。这种“手动正常、脚本调用失败”的典型原因多半是OUI脚本解析scp输出或交互逻辑与新版OpenSSH的行为不兼容。在这种受限场景下与其继续跟OUI较劲不如临时给scp套一层“壳”让它适配OUI的调用方式。但要强调这只是安装期间的临时救急手段装完大库之后必须立刻恢复原文件、移除所有临时脚本和密码痕迹。3.2 用户级wrapper脚本的实现方式我的做法是分两层先试用户级不修改系统文件失败再上系统级。用户级的意思是在grid用户自己的~/bin目录下放一个名叫scp的脚本然后把这个目录放到PATH的最前面。OUI在验证互信时是通过PATH查找scp命令的所以只要PATH优先就会找到我们包装过的版本。这个脚本的核心逻辑是不用系统默认的scp去跟OUI的expect交互而是用sshpass把密码自动喂给真正的scp。脚本内容大概长这样# 文件路径: /home/grid/bin/scp #!/bin/bash exec /usr/bin/sshpass -p Grid2025 /usr/bin/scp $注意几个关键点。第一密码绝对不能出现在脚本里被别人看到所以脚本权限要收紧chmod 700 /home/grid/bin/scp chown grid:oinstall /home/grid/bin/scp第二PATH要在~/.bash_profile里设置确保grid用户通过图形终端或者OUI启动时继承到export PATH/home/grid/bin:$PATH第三sshpass这个工具在最小化安装的Linux 8.3上通常没有需要先确认which sshpass rpm -qa | grep sshpass如果没装而且你手头有root权限、能访问本地yum源可以安装yum install -y sshpass如果连软件源也用不了就用expect来替代下面会单独讲。3.3 系统级替换与回滚步骤用户级wrapper有一个软肋如果OUI脚本在某个环节调用了/usr/bin/scp这种绝对路径用户级的PATH scheme就失效了。我当时第一次重试日志里仍然报scp错误用strace跟踪OUI进程才发现它调用了绝对路径。这时候才决定动系统文件。系统级操作分七步每一步都不能省# 1. 备份原始scp cp -a /usr/bin/scp /usr/bin/scp.bak # 2. 编写wrapper脚本覆盖到/usr/bin/scp cat /usr/bin/scp EOF #!/bin/bash # 仅用于安装Oracle 19c RAC期间临时替代安装完成后必须恢复 exec /usr/bin/sshpass -p Grid2025 /usr/bin/scp.bak $ EOF # 3. 加上执行权限保持属主不变 chmod 755 /usr/bin/scp chown root:root /usr/bin/scp # 4. 检查SELinux context是否需要修复 restorecon -v /usr/bin/scp第4步容易被忽略因为直接新写的文件context可能不对导致即便有执行权限也被SELinux拦住。执行完restorecon之后用OUI重试互信检查。确认安装通过后回滚操作是终局# 5. 恢复原始scp mv /usr/bin/scp.bak /usr/bin/scp # 或者 cp -a /usr/bin/scp.bak /usr/bin/scp # 6. 删除临时文件清理密码痕迹 rm -f /home/grid/bin/scp sed -i /\/home\/grid\/bin/d ~/.bash_profile # 7. 验证scp功能恢复正常 scp ~/test.txt node2:~回滚操作我建议在Grid Infrastructure的root.sh和orainstRoot.sh跑完之后再做。虽然理论上装完GI之后OUI不再需要scp了但保险起见等到两个root脚本执行完成、集群正常启动之后再恢复。3.4 依赖工具缺失时的备选expect脚本如果内网环境装不了sshpass还有一条路用系统自带的expect写交互脚本。expect在Linux 8.3上默认可能也没有但有些基础环境会装上。检查which expect如果有wrapper脚本可以改成罩住scp的交互行为#!/bin/bash # 文件路径: /usr/bin/scp # 用expect自动应答密码 exec expect -c set timeout 30 spawn /usr/bin/scp.bak {*}\$argv expect { \*yes/no*\ { send \yes\r\; exp_continue } \*password:*\ { send \Grid2025\r\ } \*Password:*\ { send \Grid2025\r\ } } expect eof 这个方案的好处是不装额外软件包坏处是expect对scp的交互输出依赖比较强不同OpenSSH版本提示语可能不一样容易匹配不上。建议先用小文件手动测试几次确认expect脚本稳定了再交给OUI用。4. 其他靠谱替代方案与选型对比4.1 手工配置互信后跳过自动互信在真正去替换scp之前其实还有一个非常容易被忽略的选项OUI在ssh互信步骤时如果你已经手工做好了互信可以直接选择跳过“自动设置互信”的选项。我记得gridSetup.sh界面里有个复选框大致是“Set up SSH connectivity automatically”之类的字样。如果你把这个勾去掉OUI就单纯验证现有互信而不去做自动生成密钥、自动scp分发那套动作。既然我们的互信手动验证已经全部通过了那只要它不再自动搞事检查通常就能过。这个方案比替换scp安全得多也是我后来复盘时觉得应该优先尝试的。我当时没这么干是因为界面卡在检查结果上重试按钮一直弹错没注意到有跳过自动配置的勾选。建议卡在这里的朋友先尝试这个方案不行再上scp替换。4.2 修改ssh客户端配置规避host key确认如果日志明确指向host key确认问题也就是“Host key verification failed”还有更温和的办法在grid用户的~/.ssh/config里写死对目标节点的策略。cat ~/.ssh/config EOF Host node1 node2 StrictHostKeyChecking no UserKnownHostsFile /dev/null LogLevel ERROR ConnectTimeout 10 EOF这个方法通过对客户端做配置让ssh和scp在连接目标节点时不再要求host key确认也不写入known_hosts从而避免OUI在BatchMode下被交互提示卡死。它对系统文件完全无侵入回滚也简单删掉这个config文件即可。它的局限性是如果OUI日志显示失败原因根本不是host key确认比如是scp输出解析或者算法协商失败那这个配置就帮不上忙。4.3 方案对比与选型建议方案复杂度风险适用场景手工互信跳过自动配置低低绝大多数INS-06006修改ssh客户端config低低明确为host key确认失败临时替换scpsshpass中高手动互信通过但OUI自动逻辑不兼容临时替换scpexpect中中无法安装sshpass的受限环境打OpenSSH补丁或调整sshd_config高中客户允许变更系统安全配置我的建议是第一优先手工互信跳过自动配置第二优先修改客户端config最后才用替换scp。替换scp是救场用的不是常规手段它能解决“OUI自动逻辑与新版OpenSSH不兼容”这一类壳层问题但也可能在安装过程中引发其他隐性故障所以操作时一定要留好备份和回滚脚本。5. RAC安装排障实录常见问题速查5.1 高频报错与排查方向这次排障过程中陆陆续续踩了几个典型的坑我把它们整理成速查表方便你遇到类似问题时快速对号入座。日志关键字可能原因排查动作Permission denied (publickey)authorized_keys权限/属主不对或密钥算法不匹配检查.ssh目录权限确认属主是grid:oinstall重新生成Ed25519或RSA密钥Host key verification failedknown_hosts指纹冲突清理~/.ssh/known_hosts或配置StrictHostKeyChecking noConnection refusedsshd未启动或防火墙阻断检查systemctl status sshd、firewall-cmd规则no matching key exchange methodcrypto-policy禁用了旧算法生成新密钥或修改系统crypto-policy后再试scp exited with code 1OUI与scp交互不兼容手动跑scp确认功能正常然后考虑临时替换scp方案Bad configuration optionssh_config里有当前版本不认的参数逐行检查~/.ssh/config注释掉可疑项我印象最深的是一次环境里报“no matching key exchange method”当时在ssh命令后面手工加-o KexAlgorithmsdiffie-hellman-group14-sha1能通但OUI没法传这个参数最后是重新生成了RSA密钥并调整了系统crypto-policy级别才解决。5.2 安装前把互信一次配对的检查清单吃了几次亏以后我在RAC安装前的互信步骤收敛成了一个固定清单每次按顺序执行基本能避免90%的INS-06006确认/etc/hosts配置正确短主机名和FQDN同时写上节点IP必须内网互通。清理历史互信残留删除~/.ssh下的旧文件或者完整备份后重新生成。用grid用户和oracle用户分别执行ssh-keygen -t rsa -b 2048 -N 生成新密钥对。在节点间互相执行ssh-copy-id包括localhost、短主机名、FQDN。执行双向、多主机的BatchMode验证脚本确认所有组合都免密成功。检查~/.ssh和authorized_keys权限确认属主正确。执行restorecon -R -v ~/.ssh修复SELinux context并getenforce确认状态。5.3 一些碎碎念的实战心得说实话INS-06006报错最迷惑的地方在于OUI的界面提示太笼统了永远只告诉你“互信没建立”但不告诉你具体是ssh失败还是scp失败更不会告诉你它执行了什么命令。所以我的第一原则永远是找日志而不是反复重试。确定失败阶段之后再动手解决问题否则就是在猜。如果最后真的走到替换scp这一步我提醒三个红线一是必须备份原文件备份完先验证备份文件可用二是脚本里的密码必须严格限制读取权限装完立刻清理三是回滚动作放在集群启动成功之后执行别图省事提前恢复否则root.sh阶段可能又需要scp。还有一个容易被忽略的心理因素当你用偏方把安装流程推过去之后一定要在业务空窗期做一次彻底的复盘把当时的临时配置、临时脚本、残留密码全部清除干净。我当时装完以后第二天还专门登录所有节点逐个确认/usr/bin/scp恢复成了原始状态、~/.bash_profile里没有多余的PATH设置。这个动作看似多余但能在将来某次安全审计时救你一命。最后再分享一个小技巧整个过程中让我最意外的是真正卡住OUI的往往不是密钥或权限这类“硬配置”而是软件交互层面的变化。OpenSSH每个版本都在调整输出和交互行为而Oracle的cvu脚本里写死了对老版本的预期这中间的空档就造成了大量莫名其妙的INS-06006。如果你也遇到类似情况建议先在测试环境里跑一遍strace -f -e tracenetwork,execve -o /tmp/oui_strace.log ./gridSetup.sh看看OUI到底调了哪些ssh和scp命令、传给它们什么参数。有些时候你会发现它调用了一个你完全没想到的命令比如用rcp或者带特殊参数的scp -o SomeOption。那时候就能对症下药而不是盲猜。我个人的体会是替换系统命令这种偏方能用但一定要清楚它的代价和边界。它救急能力很强但绝不能当作长期方案留在机器上。装好RAC、集群正常跑起来之后把系统恢复干净再回头梳理OUI与OpenSSH版本差异才是上策。