SSH免密登录原理与配置：authorized_keys及文件权限全解析

2. 核心原理拆解：为什么“文件操作”是免密登录的灵魂

免密登录的实现无外乎“A机器要能证明自己的身份，B机器愿意相信并放行”，这背后完全靠的是一对密钥文件和一个授权文件的配合。

先理清两个角色。你日常操作的机器叫客户端，它持有私钥（默认是~/.ssh/id_rsa），私钥绝不能泄露，它的作用就是“签名”，向服务端证明“我是我”。目标服务器叫服务端，它存放着所有被信任客户端的公钥，这些公钥被集中写进一个名叫authorized_keys的文件里。当客户端发起连接时，服务端生成一段随机数据发给客户端，客户端用私钥签名后返回，服务端再用authorized_keys里的公钥去验证签名。如果数学上匹配成功，那就免密放行。这个过程叫做公钥认证，核心其实就是一个“签名—验签”的文件读写动作。

既然原理是文件读写，那么所有配置步骤自然就能用文件创建、追加、变更权限、移动与对比来精确控制。对这个逻辑的理解程度，直接决定了你后续排障能力的高低。

拿我自己举例。我有三台CentOS 7.9机器，经常需要在它们之间相互跳转，批量执行命令或同步日志，不可能每台机器都轮着输入一遍密码。我的目标是把web-server-01这台机器做成一个“运维跳板机”，从它出发可以免密登录到另外任意一台机器。围绕这个目标，我的全部操作就是三件事：创建密钥文件、分发公钥文件、核对文件权限。整个过程不碰任何第三方工具，全是系统自带的命令和文件规则。

注意：这里有一个高频混淆点，很多人会把authorized_keys和known_hosts搞混。authorized_keys是服务端的信任列表，用来放客户端的公钥；known_hosts是客户端的已知主机列表，用来记录它连接过的服务端主机指纹。两者的方向和职责完全相反，排障时千万别看错文件。

很多人觉得SSH免密登录的难点在于“不会敲命令”，但以我带过的运维新人来看，真正的拦路虎几乎都出在文件细节上：不会用cat >>正确追加文件导致把原有公钥覆盖了、搞错.ssh目录的属主导致服务端拒收、权限多了一个group写权限导致客户端直接忽略该文件。这些文件相关的细节，恰恰是整个方案里最需要死磕的部分。

3. 配置步骤精讲：如何用文件操作跑通全流程

在实际生成和分发密钥之前，先明确一个原则——先检查，再创建，最后分发，每一步都要对文件施加精准控制。我的处理思路分五步走，下面逐步拆开说明。

3.1 第一步：检查目标机上已有的密钥文件

在客户端机器上执行：

bash复制ls -la ~/.ssh/

如果输出中提示No such file or directory，说明.ssh目录都不存在，需要先创建。如果已经存在id_rsa和id_rsa.pub，就要慎重考虑——你是直接沿用旧密钥，还是备份后重新生成？

一条极为重要的运维建议：不要在一台机器上反复生成多对密钥，也不要把同一条私钥漫无目的地拷到多台机器上。私钥一旦散落，泄露面就会变大。最稳妥的做法是一台客户端统一使用一对密钥，私钥原地留存，只分发公钥。

如果之前生成过但不确定还能不能用，可先用这种方式测试本机私钥能否读取：

bash复制ssh-keygen -y -f ~/.ssh/id_rsa

这条命令会从私钥中反解出公钥内容并打印到屏幕。如果它能顺利输出以ssh-rsa或ssh-ed25519开头的一长串字符，说明私钥文件没有损坏。

3.2 第二步：创建密钥文件并理解两个关键参数

这里直接创建一个新密钥对：

bash复制ssh-keygen -t rsa -b 4096 -C "ops@web-server-01" -f ~/.ssh/id_rsa

解释一下几个参数的含义，方便你在真实环境里因需调整：

• -t rsa：指定密钥类型，也可以用ed25519，后者更短且安全性更高，但个别老版本OpenSSH可能不支持。运维建议是两边系统都是CentOS 7以上直接用ed25519，否则继续用rsa。
• -b 4096：指定密钥长度。rsa默认2048位，实测要更安全就提到4096，代价是认证时计算量稍有增加。对于内网运维环境个人感受是2048足够用，但如果服务器直接暴露在外网，建议直接4096起步。
• -C：注释信息，会写进公钥文件尾部，方便你后期辨认这把公钥是谁的。建议写“用途@主机名”这种格式。
• -f：指定私钥文件保存路径，默认就是~/.ssh/id_rsa，基本不用改。真正需要改的场景是：你已经有了一对默认密钥，但还想额外生成一对专门用于某个特殊项目的