3、SSH免密登录配置：生成密钥对、分发公钥、测试免密登录、常见问题

集群部署的第一步，往往就是打通SSH免密登录。我见过太多新手在这上面栽跟头——配了半天，结果还是输密码。说白了，SSH免密登录就是让机器之间互相认识，不用每次见面都掏身份证。

我个人习惯，在部署任何集群之前，先把所有节点的SSH免密搞定。这一步稳了，后面才顺。咱们一步步来。

3.1 生成密钥对

密钥对分两种：公钥和私钥。公钥是锁，私钥是钥匙。你把锁发给别人，钥匙自己留着。

在任意一台节点上执行：

ssh-keygen -t rsa -b 4096 -C "cluster-deploy"

参数说明：

-t rsa：指定算法类型，RSA最通用
-b 4096：密钥长度，4096位更安全
-C "cluster-deploy"：注释，方便识别

执行后，系统会问你要不要设置密码短语（passphrase）。集群部署场景下，我建议直接回车跳过。为什么？因为自动化脚本跑起来，没人坐在那里输密码。

注意：生产环境如果对安全要求极高，可以设置密码短语，配合ssh-agent使用。但集群部署初期，先别给自己找麻烦。

生成的文件默认在 ~/.ssh/ 目录下：

id_rsa —— 私钥，千万别泄露
id_rsa.pub —— 公钥，可以随便分发

3.2 分发公钥

公钥生成好了，接下来要把它发到所有目标节点上。我常用的方式有两种。

方式一：ssh-copy-id（推荐）

ssh-copy-id -i ~/.ssh/id_rsa.pub user@node1
ssh-copy-id -i ~/.ssh/id_rsa.pub user@node2
ssh-copy-id -i ~/.ssh/id_rsa.pub user@node3

这个命令会自动把公钥追加到目标节点的 ~/.ssh/authorized_keys 文件里。省心，不容易出错。

方式二：手动追加

如果目标节点没有ssh-copy-id命令，那就手动来：

cat ~/.ssh/id_rsa.pub | ssh user@node1 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

嗯，这里要注意：authorized_keys文件的权限必须是600。我遇到过一回，公钥明明写进去了，就是登不上。查了半天，发现权限是644。你想想看，SSH检查权限很严格，权限不对直接拒绝。

  权限检查清单：
  ~/.ssh 目录权限：700
~/.ssh/authorized_keys 文件权限：600
~/.ssh 目录不能属于其他用户

3.3 测试免密登录

分发完公钥，别急着往下走。先测一下：

ssh user@node1 "hostname"
ssh user@node2 "hostname"
ssh user@node3 "hostname"

如果直接返回主机名，没让你输密码，那就成了。

如果第一次连接时弹出这个：

The authenticity of host 'node1 (192.168.1.10)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)?

这是SSH在问你要不要信任这个主机。输入yes就行。但集群里几十台机器，每台都手动yes一遍，太傻了。

我的做法是：在SSH配置里关掉这个检查。编辑 ~/.ssh/config：

Host *
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

安全提醒：生产环境不建议关掉StrictHostKeyChecking。但集群内部网络，所有节点都是你部署的，问题不大。我一般在测试环境这么配，上线前再改回来。

3.4 常见问题与避坑指南

做这行久了，踩过的坑比吃过的盐还多。下面这几个问题，我几乎每次培训都会遇到。

问题1：Permission denied (publickey)

最经典的错误。原因通常有：

公钥没正确追加到authorized_keys
权限不对（上面说过了）
SSH服务端配置没开公钥认证

检查目标节点的 /etc/ssh/sshd_config：

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no   # 如果关掉密码登录，必须确保公钥认证能通

改完配置记得重启sshd：systemctl restart sshd

问题2：known_hosts冲突

集群重建或者IP重分配后，你可能会遇到这个：

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

这是因为目标主机的密钥变了，但本地known_hosts里还记着旧的。解决办法：

ssh-keygen -R node1
ssh-keygen -R 192.168.1.10

或者直接清空known_hosts：

> ~/.ssh/known_hosts

小技巧：我习惯在部署脚本里加一行 rm -f ~/.ssh/known_hosts，省得每次重建集群都要手动清理。当然，这只适合测试环境。

问题3：免密登录时好时坏

有一次，我发现node1能免密登录node2，但node2登录node1却要输密码。查了半天，原来是node1的公钥没放到node2上。双向免密，两边都要配。

解决方案：在所有节点上互相分发公钥。写个循环脚本：

for node in node1 node2 node3; do
    ssh-copy-id -i ~/.ssh/id_rsa.pub user@$node
done

问题4：SSH连接超时

这个通常不是免密配置的问题，而是网络不通。检查：

防火墙是否放行了22端口
目标主机是否在运行sshd服务
DNS解析是否正常

用 telnet node1 22 快速验证端口通不通。

3.5 知识体系总览

下面这张图，把SSH免密登录的整个流程串起来了。我建议你照着这个顺序操作，不容易漏步骤。

3.6 总结

SSH免密登录，说白了就三步：生成、分发、测试。但每一步都有细节。权限、known_hosts、双向互信，这些坑我当年都踩过。现在每次部署，我都会先跑一遍完整的测试脚本，确保所有节点之间都能畅通无阻。

记住一句话：集群越大，SSH免密越重要。你想想看，上百台机器，每台都要手动输密码，那还搞什么自动化？

我的习惯：在部署脚本里，我会把SSH免密配置写成一个独立的函数。每次新建集群，直接调用。省时省力，还不会漏节点。

想要更多资料，联系可可

📚 课程目录

3、SSH免密登录配置：生成密钥对、分发公钥、测试免密登录、常见问题

3.1 生成密钥对

3.2 分发公钥

方式一：ssh-copy-id（推荐）

方式二：手动追加

3.3 测试免密登录

3.4 常见问题与避坑指南

问题1：Permission denied (publickey)

问题2：known_hosts冲突

问题3：免密登录时好时坏

问题4：SSH连接超时

3.5 知识体系总览

3.6 总结