1. 为什么SSH互信是RAC集群的“生命线”搞过Oracle RAC的朋友都知道集群部署前有座绕不开的“大山”——配置SSH互信。我第一次接触RAC时也觉得这玩意儿有点麻烦不就是几个节点之间能无密码登录吗但真踩过几次坑之后我才明白这根本不是“登录”那么简单它是整个集群能否顺畅运行的“生命线”。想象一下你的RAC集群有两个节点db1和db2。Oracle Grid InfrastructureGI安装程序也就是我们常说的Oracle集群软件需要在所有节点上同时执行操作。比如它要在db1上启动一个服务同时也要在db2上配置一个资源。如果每次操作都需要你手动输入密码那安装程序直接就卡死了根本没法进行下去。所以SSH互信的本质是给集群软件开一张“绿色通行证”让它能在各个节点之间自由穿梭执行命令、拷贝文件就像在本地操作一样顺畅。不配置互信或者配置错了会怎样我见过最典型的场景就是安装程序跑到一半报错提示“节点间通信失败”或者“用户等效性检查未通过”。这时候你只能中断安装回头去排查SSH配置非常折腾。更隐蔽的问题是即使安装勉强通过了后期集群管理命令比如srvctl也可能因为节点间认证问题而执行失败导致资源无法正常启动或迁移那才是真正的运维噩梦。所以今天咱们不聊虚的就聚焦在RAC部署中最核心、最实用的环节如何高效、可靠地建立SSH互信。我会分享两种最主流的实践方案一种是Oracle官方提供的“自动化脚本”一键搞定另一种是更透明、更可控的“手动密钥分发”。两种方法我都用过无数次各有各的适用场景和“坑点”接下来我就掰开揉碎了讲给你听。2. 方案一官方“神器”sshUserSetup.sh5分钟搞定所有用户当你拿到Oracle Grid Infrastructure的安装介质解压之后别急着直接运行runInstaller。先钻进这个目录看看解压路径/oui/prov/resources/scripts/。宝藏就在这里——一个名叫sshUserSetup.sh的shell脚本。这是Oracle官方为DBA准备的“开箱即用”工具目标就是让你快速跨过SSH互信这道坎。2.1 脚本原理与准备工作这个脚本干了啥简单说它帮你自动化完成了手动配置SSH互信的所有步骤。它会依次在指定的用户如root、grid、oracle下生成SSH密钥对RSA和DSA然后将所有节点的公钥收集起来合并成一个authorized_keys文件最后分发到所有节点的相应用户目录下。整个过程是交互式的但基本只需要你确认几次。在运行脚本前有几步准备工作必须做扎实否则脚本跑起来也是各种报错主机名解析必须通这是最基础也最容易出错的一点。脚本里用的-hosts db1 db2参数这里的db1和db2必须是每个节点都能正确解析的主机名。你需要在每个节点的/etc/hosts文件里把所有集群节点的IP和主机名对应关系都写清楚。千万别依赖DNS生产环境里DNS解析不稳定就是灾难。你可以用ping db1和ssh db1 hostname来测试。用户和目录要存在你打算配置互信的用户root、grid、oracle必须在所有节点上都存在并且他们的家目录如/home/grid也要准备好。特别是grid和oracle用户通常我们会在安装前就创建好并保证他们的uid、gid和家目录路径在所有节点上完全一致。防火墙和SELinux临时关闭防火墙或者放行SSH端口默认22。SELinux也最好先设为permissive模式等配置完成再根据安全策略调整。我遇到过好几次脚本运行正常但互信测试失败最后发现是SELinux拦住了.ssh目录或authorized_keys文件的访问。2.2 分步执行与参数详解准备工作做完我们就可以在一个节点上比如db1执行脚本了。通常建议在root用户下执行因为它需要切换到其他用户去操作。命令看起来很简单但每个参数都有门道cd /u01/app/19.0.0/grid_1/oui/prov/resources/scripts ./sshUserSetup.sh -user root -hosts db1 db2 -advanced -exverify -confirm我们来拆解一下-user root指定要为哪个用户配置互信。注意你需要为集群安装和运行涉及的每个用户单独执行一次脚本。通常是三个root用于安装和root脚本的执行、grid集群管理软件所有者、oracle数据库软件所有者。-hosts db1 db2列出集群中的所有节点主机名用空格隔开。如果是两个以上节点比如db1 db2 db3 db4照此格式写全。-advanced这个参数很关键。它会启用更严格的检查并使用ssh-keyscan来获取主机密钥能避免一些因为已知主机known_hosts文件导致的问题。-exverify脚本执行完毕后会自动进行一次额外的互信验证确保配置真的成功了。-confirm以非交互模式运行脚本会使用默认值并自动确认提示。对于写自动化部署脚本很有用。如果是第一次手动操作可以不加这个参数看看脚本每一步都干了啥。执行过程你会看到它在生成密钥、分发文件。最后如果看到“SSH user equivalency set up successfully”这样的提示并且互信验证通过那就大功告成了。实测经验与避坑指南节点顺序有些老版本的脚本对节点列表顺序敏感。稳妥起见确保你在命令中写的节点顺序和你在其他配置如hosts文件中保持一致。权限问题脚本执行后务必检查~/.ssh目录的权限必须是700authorized_keys文件的权限必须是600。权限不对SSH会出于安全考虑拒绝使用密钥登录。验证不能省脚本自带的验证通过了也建议你手动挨个测试一下。从db1分别ssh db2、ssh db1本地再从db2重复操作。确保每个用户都能无密码登录到所有节点包括自己。有时候本地环回登录ssh localhost出问题也会影响集群软件。3. 方案二手动密钥分发把控制权握在自己手里虽然sshUserSetup.sh很方便但在一些严格管控的环境或者你需要更清晰了解底层发生了什么的时候手动配置SSH互信是更好的选择。手动配置就像自己组装一台电脑每个零件怎么来的、装在哪你都一清二楚。这种方法特别适合那些对自动化脚本心存疑虑或者环境特殊比如有跳板机、网络策略复杂的场景。3.1 核心四步操作拆解手动配置的核心流程可以总结为四个步骤每个用户grid, oracle在每个节点上都需要执行一遍。我们以grid用户在两个节点db1, db2上配置为例第一步生成密钥对在每个节点上以grid用户登录执行su - grid ssh-keygen -t rsa -N -f ~/.ssh/id_rsa ssh-keygen -t dsa -N -f ~/.ssh/id_dsa这里用了-N 表示设置空密码因为我们要的是无密码登录-f指定密钥文件路径。生成RSA和DSA两种密钥是为了兼容性虽然现在RSA基本够用但按Oracle传统做法来更稳妥。第二步创建本地授权文件还是在每个节点上将刚生成的公钥合并到授权文件cd ~/.ssh cat id_rsa.pub id_dsa.pub authorized_keys现在每个节点的grid用户家目录下都有一个authorized_keys文件但里面只包含本节点生成的公钥。第三步跨节点分发授权文件这是实现“互信”的关键。我们需要把db1上的授权文件拷贝给db2再把db2上的合并进来。从db1操作将db1的授权文件拷贝到db2scp ~/.ssh/authorized_keys griddb2:/home/grid/.ssh/authorized_keys_from_db1这里先拷贝成一个临时名字避免覆盖db2原有的登录到db2合并公钥ssh db2 su - grid cd ~/.ssh cat authorized_keys_from_db1 authorized_keys这样db2的authorized_keys里就有了db1和db2两个节点的公钥。第四步完成反向分发最后再把合并好的、包含双方公钥的authorized_keys文件从db2拷回db1覆盖掉原来的。# 在db2上执行 scp ~/.ssh/authorized_keys griddb1:/home/grid/.ssh/现在db1和db2两个节点上grid用户的authorized_keys文件内容完全一样了都包含了两个节点的公钥。双向无密码登录的通道就此打通。3.2 权限、验证与高阶技巧手动配置细节决定成败。除了流程这些点必须关注目录和文件权限这是SSH协议的安全要求必须严格遵守。~/.ssh目录权限必须是700(drwx------)~/.ssh/authorized_keys文件权限必须是600(-rw-------)~/.ssh/id_rsa(私钥) 权限必须是600你可以用一个命令快速修复权限chmod 700 ~/.ssh; chmod 600 ~/.ssh/*。彻底验证配置完后进行网格化测试。从db1执行ssh db2 date、ssh db1 date从db2执行ssh db1 date、ssh db2 date。确保每条路径都畅通并且没有出现“Are you sure you want to continue connecting (yes/no)?”这样的主机确认提示这表示known_hosts文件没记录对于自动化操作也是干扰。使用ssh-copy-id简化如果你觉得上面合并、分发的步骤有点繁琐在较新的系统上可以借助ssh-copy-id这个工具。它的作用就是把你本地用户的公钥自动追加到远程对应用户的authorized_keys文件里去。 例如在db1的grid用户下想配置到db2的免密登录可以这样ssh-copy-id griddb2执行后输入一次db2上grid用户的密码就自动完成了。但要注意这只是单向的。要实现互信你还需要在db2上对db1执行同样的操作。这个方法比纯手动更简单但依然需要你理解其单向性的本质。4. 两种方案深度对比与选型建议好了两种方法都摆在这儿了到底该选哪个这没有绝对答案得看你的具体场景。我画个简单的对比表帮你一眼看清区别特性维度自动化脚本 (sshUserSetup.sh)手动密钥分发上手速度极快一条命令配一个用户较慢需在每个节点为每个用户执行多步操作操作复杂度低隐藏底层细节高需要理解密钥生成、分发、合并的全过程可控性较低脚本是个黑盒出错时排查较难极高每一步都可控问题定位清晰环境要求依赖Oracle安装介质中的特定脚本只依赖系统自带的ssh-keygen, scp等基础工具适用场景标准环境下的快速部署、新手入门严格管控环境、需要定制化、故障排查、学习原理根据我这么多年的经验给你几条实在的选型建议如果你是RAC部署新手或者追求最快的部署速度并且你的环境比较标准主机名解析正常、防火墙已配置那么首选自动化脚本。它能帮你省下大量时间避免在手动操作中因粗心犯错。如果你的生产环境网络策略复杂比如节点之间有严格的防火墙规则、需要通过特定网关或者主机名解析方式特殊那么建议用手动方式。你可以更灵活地控制密钥分发的过程甚至结合ssh-agent等工具处理跳板情况。当自动化脚本执行失败时手动方式是最好的排查和备用方案。你可以通过手动执行每一步精准定位是密钥生成、文件权限、还是网络拷贝出了问题。从学习角度出发我强烈建议每个DBA至少完整地手动配置一次。这个过程能让你深刻理解SSH互信的原理以后无论遇到什么相关问题你都能心里有数快速解决。5. 常见故障排查与安全加固指南配置互信很少有一帆风顺的尤其是第一次。别担心我把常见的坑和解决办法都列出来你遇到问题时可以按图索骥。5.1 互信配置失败了怎么查“Permission denied (publickey,gssapi-keyex,gssapi-with-mic)”这是最经典的错误意思是SSH服务器拒绝了你的密钥认证。第一步检查权限99%的问题出在这里。立刻去远程节点比如你从db1连db2失败就去db2上检查对应用户的~/.ssh目录和authorized_keys文件权限必须严格是700和600。第二步检查文件内容确认authorized_keys文件里确实包含了发起登录节点db1的公钥。可以用cat ~/.ssh/authorized_keys查看对比一下和db1上id_rsa.pub的内容是否一致。第三步开启SSH调试模式在客户端连接时加-v参数如ssh -v griddb2。会输出非常详细的连接过程告诉你它尝试了哪些密钥、读取了哪个文件、失败的原因是什么。这是终极排查利器。“Host key verification failed.”这是因为known_hosts文件里没有目标主机记录或者记录的公钥指纹变了。对于自动化环境这很讨厌。有两个办法手动先连接一次在配置互信前先用每个用户手工ssh一下每个其他节点把主机密钥确认信息录入known_hosts。修改SSH配置谨慎在自动化脚本中可以给ssh命令加上-o StrictHostKeyCheckingno参数来跳过检查。但注意这有安全风险仅在受信任的隔离环境使用。脚本运行中途报错退出首先看错误信息。如果是连接超时检查网络和防火墙。如果是“Permission denied”检查执行脚本的用户是否有权限切换到目标用户比如root能否su - grid。还有一个常见问题是脚本路径不对或者介质解压不完整确保你cd到了正确的resources/scripts目录下。5.2 安全与维护建议配置好了不是一劳永逸安全和维护也要跟上。密钥强度现在一般推荐使用RSA 2048位或更长的密钥或者使用Ed25519算法更安全更快。ssh-keygen -t rsa -b 2048或ssh-keygen -t ed25519。DSA密钥现在被认为强度不足在新环境中可以不再生成。定期检查与更新像检查其他系统配置一样将SSH互信纳入定期审计。检查authorized_keys文件是否有异常添加的陌生公钥。如果团队成员变更或者怀疑密钥可能泄露应该重新生成并分发密钥。限制SSH配置在生产环境可以考虑修改/etc/ssh/sshd_config禁用密码登录PasswordAuthentication no只允许密钥登录这样更安全。同时可以限制某些用户只能从特定IP登录。使用配置管理工具如果你管理大量的集群或服务器可以考虑使用Ansible、Puppet等配置管理工具来维护SSH互信。这些工具可以让你用声明式的方式定义状态实现更标准化、自动化的管理。比如用Ansible的一个authorized_key模块任务就能轻松完成公钥分发。说到底配置SSH互信是RAC部署路上一个扎实的基础功。把它练熟了不仅能保证安装顺利对日后集群的稳定运行和问题排查也大有裨益。希望这两种方案和这些实战细节能帮你下次部署时更加得心应手。