上周在客户现场调一台RHEL 8.3的双节点服务器准备装Oracle 19c RAC。Grid安装前按照惯例跑了一遍cluvfy预检磁盘、内存、网络、cgroups都过了唯独卡在SSH互信这关OUI直接弹了INS-06006。当时群里问了一圈得到的建议几乎一边倒“打补丁19c的RU包能修这个。”但现场情况很现实新装的机器连补丁包都没下载完审批流程没走完安装窗口只剩两天根本等不起补丁。所以我把OpenSSH的配置、Oracle安装日志、sshd日志来回翻了几个小时最后用了一个“临时替换scp”的土办法把系统scp命令换成一层包装强制它走传统SCP协议把互信检查先哄过去等整个RAC装完再换回来。这个操作没有动Oracle任何文件也没改内核参数半小时内就在实验室环境复现并验证通过了。这篇就把完整排查链路和替换方案写出来。内容面向正在给RHEL 8.x装Oracle 19c RAC的DBA也适合在运维环境里遇到“能ssh但scp死活不行”的同行。看完你至少能判断我的环境到底该不该替换scp替换时要注意什么以及装完以后怎么安全地恢复。1. INS-06006到底卡在哪一步先看懂Oracle的互信检查逻辑1.1 报错现场的典型形态INS-06006在Grid Infrastructure安装过程中出现的位置通常是OUI执行到“SSH connectivity”这一步。如果你不是用图形界面走OUI而是像我一样习惯直接跑cluvfy预检那么这个错误也会出现在cluvfy stage -pre crsinst的“Check: SSH connectivity”项下面。报错文字往往是一句很空的描述类似“Passwordless SSH connectivity is not established among the following node(s)”紧跟其后列出节点名然后就没有更多线索了。实际上的问题范围并没有报错信息看上去那么窄。Oracle的互信检查准确的叫法是“SSH passwordless connectivity validation”检查的内容分两层检查层动作失败表现登录层从节点A ssh到节点B执行date等简单命令常见于密钥没分发、权限不对、SELinux拦截文件复制层通过scp把临时文件拷贝到对端再由ssh命令读取内容做比对常见于scp协议行为变化、sftp子系统配置被改OUI界面显示INS-06006时往往是第二层失败了。很多朋友排查时只盯着ssh能否免密登录手工执行ssh node2 date明明通的就误判为“互信没问题”。但Oracle要的是双向、可传文件、可在远端跑命令少了任何一个都会卡住。1.2 runcluvfy和OUI到底往节点间copy了什么为了弄懂它为什么需要scp我翻了一下OUI在互信检查阶段的日志。它在两个节点之间做的事情可以近似拆成三步生成一个随机文件名的临时文件比如/tmp/.oracle_ssh_test_xxxx。调用scp把这个临时文件从本节点推送到对端节点。通过ssh在远端执行cat和本地的预期内容比对验证文件内容一致。这个过程不但要测本节点到对端节点还要反过来测一次。也就是说两个节点上的oracle用户或grid用户都必须具备完整的双向免密登录、双向免密传文件能力。任何一个方向失败都会直接报INS-06006。理解这一点之后排查思路就清晰了不是去研究OUI内部代码而是手工把这个链路完整复现一遍看它倒在哪一步。如果一个干净的ssh登录都没问题但scp传文件失败那问题十有八九出在scp依赖的底层协议或sshd配置上和Oracle本身关系不大。2. Linux 8.3的SSH环境远比想象中“暗藏玄机”2.1 新版OpenSSH里scp的两种“身世”RHEL 8.3默认安装的OpenSSH版本是8.0p1。这个版本的scp命令处在一个很尴尬的过渡期OpenSSH官方从8.0开始就宣布未来要弃用传统SCP协议但直到8.7版本默认行为仍然保持传统SCP协议只是运行时偶尔会给个warning从8.8版本开始scp默认切换成SFTP协议到了9.0传统SCP协议干脆被移除了。问题在于不少企业为了合规或安全加固会在RHEL 8.3上额外升级OpenSSH包或者修改ssh客户端配置把scp默认行为调整成SFTP。这种情况下scp命令从表面看还是能用复制的底层通道却变成了sftp。Oracle 19c的互信检查逻辑对这两种协议的处理并不一致部分版本在没有安装最新RU时一旦发现scp走的是SFTP自动检查就会卡住。这和“能手工ssh但互信检查失败”的现象高度吻合。因为ssh登录不依赖sftp子系统只要密钥和权限没问题就能通而scp一旦切到SFTP协议就需要sshd开启sftp子系统。如果运维人员之前加固ssh时把sftp子系统禁用了scp自然就废了。2.2 真正让Oracle栽跟头的三个配置细节我在现场和实验室两头对比发现最容易让Oracle互信检查翻车的配置有三处第一个是Subsystem sftp被注释或删除。这个配置行通常长这样Subsystem sftp /usr/libexec/openssh/sftp-server在RHEL 8.3里如果这行被注释了scp走SFTP模式时会直接报“subsystem request failed on channel 0”。很多加固脚本为了减少攻击面会把这行干点结果就是Oracle的互信检查必然失败。第二个是~/.ssh目录和 authorized_keys 文件权限不对。RHEL 8默认开启了StrictModes对权限的要求很严格。oracle用户home目录权限超过700、.ssh目录权限不是700、authorized_keys权限不是600都会被sshd拒绝。这种问题在手工ssh时反而可能不报错因为有时候客户端和服务端针对严格模式的反馈会被某些参数掩盖但Oracle的检查不会“通融”。第三个是StrictHostKeyChecking和相关known_hosts问题。如果节点的host key在重装后变了而known_hosts里保留了旧的keyssh命令就会在中途停住OUI的自动检查没有交互能力直接判定失败。这个坑比较隐蔽因为你在终端手工ssh时系统会提示“REMOTE HOST IDENTIFICATION HAS CHANGED”你删掉旧key就过了但OUI不会等你删它只会把错误一路往上抛。我整理了一张表方便照着审查检查项正确状态异常表现Subsystem sftp未被注释scp走SFTP时报subsystem错误~/.ssh权限700ssh或scp连接直接拒绝authorized_keys权限600密钥认证失败known_hosts无过期host keySSH连接中途退出StrictModes默认开启严格校验目录权限这五个点里任何一项踩雷都有可能导致INS-06006。所以我一直主张不要上来就怀疑Oracle的补丁问题先把你自己的ssh链路收拾干净再说。3. 三步定位别急着替换先用纯手工命令确认根因3.1 第一步手工复刻互信检查定位问题最直接的办法就是把Oracle互信检查干的事手工复现一遍。以两个节点node1和node2为例先切到grid用户或oracle用户看你的安装规划然后逐条执行ssh node1 date ssh node2 date这两条通了说明基本的免密登录没问题同时会顺手把known_hosts写入补齐。接着测试scp双向传文件echo test for rac /tmp/oracle_ssh_test_$(date %Y%m%d%H%M%S) scp /tmp/oracle_ssh_test_* node2:/tmp/ ssh node2 cat /tmp/oracle_ssh_test_*这个测试里只要scp这一步报错问题就基本锁定了。我见过太多现场卡在这条上ssh能通scp死活不行Oracle报错自然也就指向INS-06006。不要跳过文件内容比对这一步。很多环境里scp文件能到对端但传的是0字节文件或者文件名都对内容不对。Oracle检查的是最终读出来的内容是否和本机一致不能只看“有没有文件”。3.2 第二步独立验证scp到底死在哪个环节手工复现报错之后下一步是给scp加上调试参数看它内部在走哪种协议scp -vv /tmp/test_scp node2:/tmp/重点关注输出里的两行。如果看到类似Sending command: scp -t /tmp说明scp在走传统SCP协议远端会通过shell再拉起一个scp进程来收文件。如果看到subsystem request for sftp或者sftp-server说明scp在走SFTP协议此时要求sshd开启sftp子系统。接着去远端节点上同时看sshd日志。RHEL 8.3的日志在/var/log/secure也可以临时用journalctl -u sshd -f跟一下journalctl -u sshd -f再在另一个终端重跑scp命令。日志里如果出现bad ownership or modes这类关键字那就是权限问题如果出现subsystem request failed那就是sftp子系统被关了如果出现command not found大概率是远端的scp可执行文件或PATH有问题。这一步的目的是把问题归类不要急着替换任何东西。很多时候根本不需要替换scp改个权限就好了。3.3 第三步区分协议行为差异还是配置权限问题我判断该不该走“替换scp”这条路的依据很简单如果ssh能通、scp显示走的是传统SCP协议但远端拒绝执行scp命令优先检查远端是否安装openssh-clients、PATH是否包含/usr/bin、shell是否正常。如果scp显示在走SFTP协议但sshd没有开启sftp子系统优先恢复sshd配置确认Subsystem sftp那一行存在并重启sshd。如果权限、子系统、known_hosts全部正常scp仍然报错且Oracle的检查脚本明显和当前OpenSSH版本行为不兼容这才考虑临时替换scp。要注意“临时替换scp”不是万金油。它解决的是“协议行为差异导致Oracle脚本不适配”这一类问题解决不了权限错误和网络问题。我在实验室验证时也发现如果权限本身就是乱的替换scp之后照样失败因为传统SCP协议在远端启动scp进程时对权限校验同样严格。4. 临时替换scp的操作实录4.1 备份原scp并准备wrapper脚本确认根因之后我开始在两台节点上执行替换。这里先解释一下思路原系统的scp是二进制文件不能直接改内部逻辑所以我的做法是把原文件改名为备份文件然后写一个shell包装脚本在调用原scp时强制加上-O参数让scp死心塌地走传统SCP协议。在node1和node2上都执行cp -a /usr/bin/scp /usr/bin/scp.real cat /usr/bin/scp EOF #!/usr/bin/env bash exec /usr/bin/scp.real -O $ EOF chmod 755 /usr/bin/scp这里有个参数细节必须说清楚在新版OpenSSH中-O是“use the original SCP protocol”的意思也就是强制走传统SCP协议-s才是强制走SFTP协议。OpenSSH 8.x版本都支持-O所以RHEL 8.3上这个方案成立。如果你用的是OpenSSH 9.0以上环境-O选项可能还在但传统协议支持已经不完整这个方案就不能照搬了。还有一个容易踩的坑所有RAC节点都要同时替换不只是第一个节点。传统SCP协议的工作方式是本地scp连接远端sshd之后远端通过shell再执行一个scp -t 路径的命令来接收文件。如果远端节点的scp没被替换远端启动的可能还是原生的scp行为两边协议不一致照样失败。4.2 sshd侧的配套设置替换完scp还不是万事大吉。传统SCP协议虽然不依赖sftp子系统但如果你之前把sshd_config里的sftp子系统注释掉了我建议还是顺手恢复避免Oracle检查过程中有别的脚本走sftp通道到时候报错更莫名其妙。检查并恢复配置的方法grep -E ^Subsystem /etc/ssh/sshd_config如果没有这一行在文件末尾加Subsystem sftp /usr/libexec/openssh/sftp-server然后重启sshdsystemctl restart sshd同时别忘了重置关键目录的SELinux上下文特别是oracle用户和grid用户的home目录。RHEL 8上SELinux对ssh的约束很微妙有时候你看着权限都是755、600但因为没有restorecon上下文还是错的。执行一行恢复命令很有必要restorecon -R -v ~oracle/.ssh ~grid/.ssh 2/dev/null || true替换scp、恢复sftp子系统、修好上下文这三件事要一起做。只做其中一个还是可能遇到莫名其妙的失败。4.3 替换后的互信验证与安装推进替换完成后不要直接去点OUI的“重试”先手工把Oracle要做的检查完整跑一遍ssh node1 date ssh node2 date echo verify | scp -v node1:/dev/stdin node2:/tmp/oracle_scp_check 21 ssh node2 cat /tmp/oracle_scp_check我的现场验证结果是手工scp瞬间通过了而且debug输出里明确显示远端起的是scp -t进程说明路径确实切回了传统SCP协议。接着重跑cluvfy$GRID_HOME/bin/cluvfy stage -pre crsinst -n node1,node2 -verbose跑到SSH connectivity那一项时直接通过。OUI界面如果还是显示失败状态可以选择重新执行“SSH connectivity”检查或者干脆跳过自动配置SSH这一步因为此时互信已经建立好了不需要OUI再做一次。这个技巧在图形界面安装时比较省事很多人不知道实际上OUI的检查项是可以手动跳过的。既然互信已经通了后面Grid Infrastructure的安装就不会再被卡在INS-06006。我去泡了杯咖啡回来时OUI已经跑到root脚本执行阶段了。5. 这套“骚操作”的边界与收尾能救急但别留坑5.1 替换scp的系统性影响评估临时替换scp能解决眼前的问题但副作用必须想清楚。最直接的影响是所有调用/usr/bin/scp的自动化脚本都会默认走传统SCP协议并加上-O参数。对于绝大多数文件复制场景这没有问题但如果某个自动化程序已经显式指定了SFTP相关参数再叠加-O有可能触发参数冲突。举个例子如果你的运维平台通过scp向集群节点分发软件包而平台自身依赖SFTP的某些增强功能这个wrapper就会把平台的行为带偏。我在客户现场是运气好那台机器上除了安装Oracle之外没有其他业务自动化在跑所以替换期间没有副作用。但如果你的节点上已经部署了ansible、监控Agent或CI/CD组件替换前一定要评估影响面。还有一点这个方案只在OpenSSH 8.x版本下验证有效。如果节点后来升级过OpenSSH到9.x传统SCP协议被正式移除-O参数可能还在但远端能不能按老方式启动scp进程就不好说了。所以这台机器在安装完成后我的第一建议仍然是申请补丁窗口把Oracle RU打上然后恢复到原生scp。5.2 安装完成后的回滚与清尾RAC装完、数据库实例正常拉起之后我做的第一件事就是把scp恢复原样不能让它留在生产环境里成为隐患。回滚很简单mv /usr/bin/scp.real /usr/bin/scp chmod 755 /usr/bin/scp执行完后用包管理器校验一下文件完整性rpm -V openssh-clients如果输出里没有异常提示说明scp已经回到了rpm包安装时的原始状态。我习惯再跑一次手工scpecho rollback check | scp node1:/dev/stdin node2:/tmp/确认基本功能正常再清理掉之前可能留下的wrapper调试日志、多余的备份文件。这里最容易被忽视的是既然改了scp就一定要在运维文档里留下记录。我曾经遇到过同行接手一台机器发现/usr/bin/scp是个脚本以为被人入侵了查了半天。实际上是上一个人做完临时替换忘了回滚也没有任何交接文档。这个问题比INS-06006本身更让人头大。5.3 官方补丁路径与后续运维建议最后还是要把话说全。“临时替换scp”只是应急方案不是根治手段。INS-06006在Oracle 19c的后续补丁版本中已经被作为已知问题修复过尤其是19.7以上的RU对RHEL 8.x的OpenSSH行为做了更好的兼容。因此装完系统、业务窗口允许的情况下还是要走标准补丁流程下载对应平台的最新Grid Infrastructure Release Update仔细看readme和已知问题列表。在grid用户下执行opatch lsinventory记录当前补丁基线。停掉集群服务按顺序应用补丁并验证。补丁结束后确认scp已经保持原生状态再跑一遍cluvfy。替换scp这个过程本质上是在补丁还没到位时给Oracle的互信检查“人工铺了一条它认识的路”。等官方补丁上来之后Oracle会按新逻辑正常调用ssh和scp不再需要这个wrapper。我在这次项目实施里最大的体会是RAC安装报错很多都出在“基础系统组件行为变化”上而不是Oracle本身。新版OpenSSH、systemd、SELinux、防火墙策略每一个都可能让安装过程出现看起来和数据库完全无关的幺蛾子。遇到INS-06006先沉住气把ssh链路一层层剥开找到真正卡壳的环节再去解决。临时替换scp是一个好手段但好手段也意味着高风险用之前评估清楚用之后及时收尾才是规范的运维姿势。