authorized_keys 与known_hosts区别与联系？

原创于 2025-11-06 10:13:19 发布 · 771 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#linux #ssh

Linux 专栏收录该内容

5 篇文章

订阅专栏

总结：authorized_keys是本机作为服务端，记录哪些客户端的公钥可以来连接；known_hosts是本机作为客户端，记录的是可以连接的服务端的公钥指纹。

好的，这是一个非常核心的SSH概念。authorized_keys 和 known_hosts 都存在于 ~/.ssh/ 目录下，都涉及公钥认证，但它们的目的、角色和方向是完全相反的。

简单来说：

authorized_keys：我是服务端，这里记录的是“我信任哪些客户端”。
known_hosts：我是客户端，这里记录的是“我信任哪些服务端”。

1. authorized_keys （服务端信任名单）

角色与目的

角色：你的机器充当 SSH服务器。
目的：这个文件列出了被授权访问你当前这台机器的所有客户端的公钥。当有人尝试SSH登录你的机器时，SSH服务会检查他的私钥是否与此文件中记录的某个公钥配对。如果配对成功，就允许登录。

文件位置

~/.ssh/authorized_keys （在SSH服务器上）

工作原理

客户端（例如 laptopA）将其公钥（id_rsa.pub）拷贝到服务器（例如 serverB）的 authorized_keys 文件中。
当 laptopA 尝试 SSH 连接 serverB 时，会说：“你好，我是 laptopA，我想用我的私钥登录。”
serverB 回应一个随机生成的挑战字符串。
laptopA 用自己的私钥对这个挑战进行签名，并将签名发回给 serverB。
serverB 用 authorized_keys 中存储的 laptopA 的公钥来验证这个签名。
验证成功，登录被授权。

典型应用场景

免密登录：这是实现SSH免密码登录的关键文件。
自动化脚本：允许脚本（如CI/CD流水线）无需人工输入密码即可登录服务器。

2. known_hosts （客户端信任名单）

角色与目的

角色：你的机器充当 SSH客户端。
目的：这个文件记录了所有你曾经连接过的SSH服务器的公钥指纹。它的核心作用是防止中间人攻击。当你第一次连接一台新服务器时，SSH客户端会让你确认服务器的指纹，确认后就会将其记录在 known_hosts 中。下次再连接时，客户端会校验服务器的公钥是否与记录的一致，如果突然变了，就会发出严重警告。

文件位置

~/.ssh/known_hosts （在SSH客户端上）

工作原理

当你第一次SSH连接一台新服务器（例如 serverX）时，你的客户端会看到 serverX 发来的它的主机公钥。

客户端会显示一个警告，类似于：

The authenticity of host 'serverX (192.168.1.100)' can't be established.
RSA key fingerprint is SHA256:xxxxxxxx...
Are you sure you want to continue connecting (yes/no)?

如果你输入 yes，客户端就会将 serverX 的主机名、IP和其公钥保存到 known_hosts 文件中。
此后，每次连接 serverX，客户端都会校验其发来的公钥是否与 known_hosts 中记录的一致。如果不一致，就会报错：
```
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
```
这提示你服务器身份可能被冒用，或者服务器密钥确实被重置了（比如重装了系统）。

对比总结表

特性	authorized_keys	known_hosts
角色	服务端	客户端
目的	认证用户（谁可以登录我）	验证服务器（我连接的是不是真的它）
内容	客户端的公钥	SSH服务器的公钥
安全问题防护	防止未授权用户登录	防止中间人攻击（服务器伪装）
文件位置	在目标服务器的 `~/.ssh/` 下	在发起连接的机器的 `~/.ssh/` 下
通俗比喻	门的允许进入名单	你认识的商家名片夹

联系与互动

它们都使用非对称加密技术（RSA， ECDSA， Ed25519等）。
在一个完整的SSH连接建立过程中，两者都会发挥作用：
1. 客户端使用 known_hosts 来验证它连接的是正确的服务器。
2. 服务器使用 authorized_keys 来验证尝试登录的客户端用户是否有权限。

举个例子：
你用办公室电脑 OfficePC 通过SSH登录到数据中心的一台服务器 DataServer。

在 DataServer (服务端) 的 /home/yourname/.ssh/authorized_keys 文件中，保存着 OfficePC (客户端) 的公钥。这样你才能免密登录。
在 OfficePC (客户端) 的 /home/yourname/.ssh/known_hosts 文件中，保存着 DataServer (服务端) 的公钥指纹。这样你才能确认连接的不是假冒的服务器。

希望这个解释能帮助你彻底理解它们的区别与联系！

是的，你说得非常对！公钥指纹本身是设计为人类可读的，但它的内容确实是不可读的随机字符串。

公钥指纹的本质

什么是公钥指纹

公钥指纹是对公钥进行哈希运算后得到的固定长度的摘要，就像人类的指纹一样：

唯一性：每个公钥对应唯一的指纹
不可逆：无法从指纹反推出原始公钥
固定长度：无论原始公钥多长，指纹长度固定

指纹的显示形式

# 常见的指纹格式
SHA256:uNiVqksVdw4eX+U2FpBDbMOaN8eQqZbHgjdNKf2bbYc
MD5:a0:8b:15:3d:fd:35:7c:8e:12:9a:4e:77:7f:2e:5e:33

为什么设计成这样

1. 安全性考虑

如果指纹可读（如"server-01-beijing"），攻击者很容易伪造
随机字符串提供了真正的唯一标识

2. 技术实现

# 公钥本身是这样的长字符串
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCwY...（很长很长）

# 经过SHA256哈希后得到指纹
SHA256:uNiVqksVdw4eX+U2FpBDbMOaN8eQqZbHgjdNKf2bbYc

3. 验证方式

虽然指纹本身不可读，但提供了验证机制：

首次连接时验证

# 当你第一次连接时看到：
The authenticity of host '192.168.1.100 (192.168.1.100)' can't be established.
ECDSA key fingerprint is SHA256:uNiVqksVdw4eX+U2FpBDbMOaN8eQqZbHgjdNKf2bbYc.
Are you sure you want to continue connecting (yes/no)?

如何正确验证

电话确认：打电话给服务器管理员核对指纹
带外验证：通过其他安全渠道获取正确指纹
Web界面：有些云服务在控制台显示服务器SSH指纹
物理访问：直接到服务器上查看

实用的指纹检查命令

查看本地已知的指纹

# 查看known_hosts中某个主机的指纹
ssh-keygen -F 192.168.1.100

# 查看所有已知主机的指纹
ssh-keygen -l -f ~/.ssh/known_hosts

查看远程服务器指纹

# 获取远程服务器的指纹（在连接前验证）
ssh-keyscan 192.168.1.100 | ssh-keygen -lf -

查看自己的公钥指纹

# 查看id_rsa.pub的指纹
ssh-keygen -lf ~/.ssh/id_rsa.pub

总结

公钥指纹确实是不可读的随机字符串，这是出于安全考虑的设计：

✅ 优点：防止伪造，提供真正的唯一标识
⚠️ 缺点：需要额外的验证步骤来确认指纹的真实性

这种设计确保了SSH连接的安全性，虽然增加了一些验证的麻烦，但这是防止中间人攻击的必要代价。