Oracle RAC配置中SSH互信的实战要点与避坑指南
在部署Oracle RAC时，SSH互信配置是前期准备工作中至关重要的一环，却也是许多工程师的“滑铁卢”。问题往往不在于步骤本身，而在于那些官方文档语焉不详、但实际部署中却一踩一个准的细节。下面，我们就来拆解几个关键环节，看看如何一次性打通所有节点，避免在后续的cluvfy校验中反复碰壁。
为什么 ssh-keygen 生成的密钥必须用 -t rsa -b 2048（不能默认或选 ed25519）
第一个坑，从生成密钥那刻起就埋下了。如今，新版本的OpenSSH默认会生成更现代的ed25519密钥，但这在Oracle RAC（尤其是11g/12c甚至部分19c版本）的环境里行不通。官方文档白纸黑字要求使用RSA算法，一些老版本的Grid Infrastructure根本不识别ed25519。你猜怎么着？这时候即便你手动加上-o hostkeyalgorithms=+ssh-ed25519参数试图补救，也常常无济于事。
所以，最稳妥的做法是从源头锁定格式：
- 统一执行
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""。这条命令强制生成2048位的RSA密钥，确保了最广泛的兼容性。 - 注意那个
-N ""，它代表空密码。这是实现真正无交互登录的关键，否则ssh-copy-id时还是会卡住让你输入。 - 生成后别急着走，立刻用
ls -l ~/.ssh/id_rsa*检查权限。私钥id_rsa必须是600，公钥id_rsa.pub必须是644。权限不对，SSH守护进程会直接拒绝读取，之前的功夫全白费。
如何让 ssh-copy-id 一次跑通所有 RAC 节点（含 localhost）
密钥对了，分发环节又有新讲究。RAC要求每个节点不仅能免密登录其他节点，还必须能免密登录自己——这里的“自己”包括localhost和本机的hostname。缺了哪一个，cluvfy校验都会直接亮红灯。但ssh-copy-id默认并不支持拷贝到本地回环地址。
可以试试这个批量操作脚本：
- 先把所有目标节点列出来：
NODES="node1 node2 localhost $(hostname)"。务必把$(hostname)（你的机器主机名）也加进去。 - 然后循环执行：
for n in $NODES; do ssh-copy-id -i ~/.ssh/id_rsa.pub $n; done。 - 这里特别要强调
$(hostname)的重要性。因为Oracle内部很多脚本是通过解析主机名来通信的，它认的不是localhost或IP地址，就是你执行hostname命令返回的那个字符串。 - 如果某个节点报
Permission denied (publickey)，先别慌。手动ssh $n date测试一下。如果不行，首要怀疑目标节点的/etc/hosts文件，看看是否把本机IP正确映射到了主机名上。
~/.ssh/config 里哪些配置会破坏 RAC 的 SSH 自动发现
这是高级用户最容易翻车的地方。你本地的~/.ssh/config配置文件用得很顺手，可能配置了全局袋里、别名或特定密钥。但Oracle的addNode.sh、root.sh等工具在运行时，有时会绕过用户级的这个配置文件，有时却又会读取它。行为不一致，导致问题隐蔽。
一旦你的config文件里存在Host *全局匹配、ProxyCommand跳转或者自定义的IdentityFilePRVF-7532 : Failed to connect to node这种令人困惑的错误。
给你的建议是：
- 在配置RAC期间，最安全的方法是临时将
~/.ssh/config重命名（例如config.bak），待配置完成后再恢复。 - 绝对不要在config文件中为RAC节点设置
StrictHostKeyChecking no。这会让cluvfy认为SSH连接不安全而直接中止检查。 - 如果因为开发环境等原因必须保留config文件，那么至少确保没有
Host *这种全局块，并且针对RAC节点，显式指定IdentitiesOnly yes和IdentityFile ~/.ssh/id_rsa，锁定密钥路径。
验证阶段最容易被忽略的三个检查点
很多人以为ssh-copy-id成功就万事大吉，结果跑cluvfy stage -pre crsinst时依然失败。原因在于，Oracle对“SSH连通”的定义比我们日常的理解要严苛得多。
在最终验证时，务必完成以下三个检查：
- 全路径测试：在每个节点上，手动执行
ssh node1 date; ssh node2 date; ssh $(hostname) date; ssh localhost date。这四个命令必须都能瞬间返回结果，不能有任何一次出现密码提示、交互询问或超时等待。 - 检查服务端配置：登录到每个目标节点，检查
/etc/ssh/sshd_config文件。必须确认PubkeyAuthentication yes是开启的，并且AuthorizedKeysFile的路径是.ssh/authorized_keys（注意，不是.ssh/authorized_keys2）。修改后记得重启sshd服务。 - 检查密钥文件格式：打开
~/.ssh/authorized_keys文件，确保文件末尾没有多余的空行或不可见的乱码。Oracle用于解析密钥的组件对格式异常敏感，有时多一个换行符都可能导致Authentication refused: bad ownership or modes这种看似权限问题的报错。
说到底，配置Oracle RAC的SSH互信，真正的挑战从来不是执行那几条命令，而是背后环环相扣的细节：主机名解析链条是否完整、sshd服务的权限控制是否严格、以及Oracle自身那套极为挑剔的校验逻辑。漏掉其中任何一环，都可能让你在深夜面对PRVF-4657或CRS-2672这类报错时一筹莫展。按照上述要点逐一排查，方能确保这条基础通道坚实可靠。
