主备免密需按角色明确主备，主节点以目标用户生成密钥并分发，ssh-keygen必须在主节点执行，ssh-copy-id须显式指定用户和端口，脚本需校验hosts/known_hosts一致性及authorized_keys权限为600。
主备免密不是“配一次就全通”，而是必须按角色明确谁是主、谁是备，并分别在主节点生成密钥、分发到所有备节点；脚本化关键在于避免手敲重复命令，但不能跳过权限和路径校验。
ssh-keygen 必须在主节点以目标用户身份执行
公钥体系是单向信任：只有主节点的私钥能解密它自己发出的请求，所以密钥必须在主节点上生成，且必须用后续要用于登录的用户（如 hadoop、deploy）执行 ssh-keygen -t rsa。若用 root 生成再拷给普通用户，~/.ssh 所属用户和权限会错乱，导致 ssh 拒绝读取私钥。
- 执行前先确认当前用户和家目录：
whoami和echo $HOME - 强制指定密钥路径，避免默认覆盖已有密钥：
ssh-keygen -t rsa -f ~/.ssh/id_rsa_master -N "" - 生成后立刻检查权限：
ls -ld ~/.ssh ~/.ssh/id_rsa_master，应为drwx------和-rw-------
ssh-copy-id 分发时必须显式指定用户和端口
ssh-copy-id 默认用当前用户登录远端，且走 22 端口。若备节点用的是非默认用户（如 hadoop@slave1）或非标准 SSH 端口（如 2222），不加参数会失败并静默创建空 authorized_keys，后续登录仍要密码。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 正确写法示例：
ssh-copy-id -i ~/.ssh/id_rsa_master.pub hadoop@slave1 - 非标端口加
-p参数：ssh-copy-id -p 2222 -i ~/.ssh/id_rsa_master.pub deploy@backup-server - 若提示
No identities found，说明本地没找到公钥文件，检查-i路径是否拼错，或公钥是否真被生成（ls ~/.ssh/id_rsa_master.pub）
脚本中必须校验 /etc/hosts 和 known_hosts 一致性
脚本批量执行 ssh-copy-id 前，如果 /etc/hosts 未同步，或目标主机首次连接时 known_hosts 缺失指纹，脚本会卡在交互式确认（Are you sure you want to continue connecting?），导致自动化中断。
- 提前统一 hosts：用
scp /etc/hosts user@slaveX:/tmp/hosts && ssh user@slaveX "sudo cp /tmp/hosts /etc/hosts" - 绕过首次确认（仅限可信内网）：
ssh-copy-id -o StrictHostKeyChecking=no -i ... - 更稳妥做法：先用
ssh -o ConnectTimeout=5 -o BatchMode=yes user@host exit 2>/dev/null预探测连通性
备节点无需生成密钥，但需确保 authorized_keys 权限为 600
主备模型下，备节点只接受主节点连接，自身不主动发起 SSH 登录，因此不需要生成密钥对。但 authorized_keys 文件权限若不是 600（即 -rw-------），OpenSSH 会直接忽略该文件，即使内容正确也无效。
- 脚本中加入修复命令：
ssh user@slaveX "chmod 600 ~/.ssh/authorized_keys 2>/dev/null || true" - 常见陷阱：用
cat id_rsa.pub >> authorized_keys追加后，文件可能继承 shell 的 umask（如 002），导致权限变成 602，ssh 拒绝加载 - 验证方式：
ssh -o LogLevel=DEBUG3 user@slaveX exit 2>&1 | grep "Offering public key"，看到这行才说明公钥被真正识别
最易被忽略的一点：主节点自己的 ~/.ssh/known_hosts 里必须有所有备节点的 host key 记录，否则脚本里后续用 ssh user@slaveX command 执行远程命令时，仍会因 host key 变更或缺失而失败——这不是免密问题，而是信任链不完整。
