分析数字证书的签名和验证以及 RSA 非对称加密解密的时候，又想到了 SSH 中登陆流程，服务器是如何在 authorized_keys 找到当前登陆客户端与之匹配的公钥呢？？

1. RSA 非对称加密解密

公钥加密，私钥解密:
记忆口诀: 加密的数据，只希望自己能解密，那么公钥加密，私钥解密。
因为非对称加密的性能比对称加密的性能低，所以，在加密通信中，往往使用的是对称加密，而对称加密使用的密钥是通过非对称加密来传输的。
- 客户端生成一个随机密钥串，然后通过服务端的公钥加密发送给服务端。
- 服务端使用私钥，解密获取随机密钥串。
- 服务端和客户端使用随机密钥串的对称加密来进行通信。

2. 签名和验证

私钥加密（生成签名），公钥验证（验证签名）:
记忆口诀: 自己提供了一段数据，希望别人能相信一定是自己提供的，那么私钥加密，公钥就可以验证。

签名和验证，目的是为了证明数据确实是私钥持有人发出来的。
生成签名: 直接对消息进行加密，此时不是为了对消息保密，而是为了签名。
验证签名: 验证者通过公钥解密消息，如果和原消息一直，则认为签名成功。

通常，由于消息可能会很长，所以往往是对消息做一个散列值，然后再在签名操作，提高效率。

客户端发送一条 ClientHello 给服务端,包含：
- 支持的协议版本，例如 TLS 1.0
- 客户端支持的对称/非对称加密算法，压缩方式
- 客户端生成的随机数1
服务端收到消息后，回一条 ServerHello :
- 确定使用的对称/非对称加密算法，压缩方式
- 服务端的 SSL 证书，证书包含的内容(证书的发布机构,证书的有效期,公钥,证书的持有者,签名)
- 服务端生成的随机数2
客户端收到后服务端的消息后：
- 校验证书
- 生成一个随机数3。通过 3 个随机数计算出最终的会话密钥，并用服务端的公钥加密，发送给服务端，告诉服务端，后续将会采用会话密钥使用协定的对称加密算法发送消息。
服务端收到消息后，解密密钥。服务端确认握手结束，下一步开始使用协商的对称加密算法 + 会话密钥通信。

校验证书，是为了防止中间人攻击，保证服务端的证书是可信的。

指纹：数字证书的主题的 HASH 值。
签名：使用 CA (证书管理机构) 的私钥，对指纹做的签名（加密）。

浏览器获取到证书后，取出证书中的签名部分，用自身根证书中对应的证书的公钥进行解密，如果解密成功，再生成HASH值和获取到的证书中的指纹来比较是否一致。