SSH 第一课：连接那几秒发生了什么

你每天敲 ssh user@host，回车，几秒后就进去了。但这几秒里，客户端和服务端完成了一件很复杂的事：在完全不信任对方的前提下，建立一条安全的加密通道。

三个阶段

阶段 1

TCP 连接

和所有网络连接一样，先三次握手。客户端连到服务器的 22 端口（默认）。这一步和 SSH 协议无关，纯粹是 TCP 的事。

客户端 → SYN → 服务器
客户端 ← SYN+ACK ← 服务器
客户端 → ACK → 服务器

阶段 2

密钥交换 + 服务器认证

TCP 连上后，双方要做两件事：

协商加密算法 — 客户端和服务端各有一份支持的算法列表，取交集。比如双方都支持 curve25519-sha256，就用它。
生成共享密钥 — 用 Diffie-Hellman 密钥交换（后面会专门讲），双方各自算出同一个密钥，全程不传输密钥本身。

关键点：这一步完成后，双方有了同一个密钥，后续所有通信都用这个密钥加密。但此时客户端还不知道对面真的是目标服务器，可能是个中间人。

所以服务端会把自己的主机密钥（host key）发给客户端。客户端第一次连接时会问你：

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

你输入 yes，这个指纹就被保存到 ~/.ssh/known_hosts。以后再连，客户端会自动比对。如果指纹变了，说明服务器被替换或有中间人攻击。

阶段 3

用户认证

通道加密了，服务器身份确认了，最后证明"我是我"。SSH 支持多种方式：

密码认证 — 最简单，密码通过加密通道传输，但容易被暴力破解
公钥认证 — 你生成一对密钥，公钥放服务器，私钥留本地。服务器用你的公钥加密一个随机数，你能用私钥解出来就证明是你
证书认证 — 企业环境常用，后面讲

你日常用的 ssh user@host 大概率走的是公钥认证。因为服务器上配了你的公钥，客户端自动用对应的私钥响应。

完整的连接日志

动手试

运行这个命令，观察输出：

ssh -v user@106.54.161.116 2>&1 | head -60

在输出中找这几行：

SSH-2.0-OpenSSH_8.9 — 协议版本协商
Host key algorithm: ssh-ed25519 — 服务器用的主机密钥算法
kex: algorithm: curve25519-sha256 — 密钥交换算法
Offering public key: ~/.ssh/id_ed25519 — 客户端尝试的认证方式
Authentication succeeded — 认证成功

为什么理解这个很重要

当你遇到 SSH 问题时，知道它卡在哪个阶段，就知道去哪里找原因：

小测验

卡在	可能原因
阶段 1	防火墙、端口没开、服务器没启动 sshd
阶段 2	主机密钥变了（known_hosts 冲突）、算法不兼容
阶段 3	密钥没配对、权限不对、sshd 配置拒绝

测一下

你第一次 ssh 连接到一台新服务器，看到 fingerprint 确认提示。这发生在哪个阶段？

A. TCP 连接

❌ TCP 是纯网络层，不涉及 SSH 协议。

B. 密钥交换 + 服务器认证

✅ 指纹确认是服务器认证的一部分。客户端第一次见到这个主机密钥，需要你确认是否信任。

C. 用户认证

❌ 用户认证是证明"我是用户"，不是确认服务器身份。

再测一个

SSH 连接中，对称加密密钥是什么时候生成的？

A. 你生成 SSH 密钥对的时候

❌ 那是认证用的密钥，不是会话加密密钥。

B. 密钥交换阶段

✅ Diffie-Hellman 密钥交换让双方各自算出同一个共享密钥，用于后续对称加密。

C. 用户认证成功后

❌ 认证发生在加密通道建立之后，不是之前。

下一步

下一课我们深入密钥交换——Diffie-Hellman 算法是怎么在不安全的网络上安全地协商出一个共享密钥的。