在《使用wireshark分析ssh口令登录细节》和《ssh工具，开发者必须有所了解》 这两篇文章中，我们知道了SSH登录有两种登录验证方式，其中口令登录方式使用简单，但会遇到安全问题，比如遇到中间人攻击，就会泄漏服务器的root口令。所以从安全的角度来看，建议使用另外一种登录验证方式，这就是密钥对登录方式。
密钥对验证方式对于初学者来说并不是很友好，所以我分两篇文章把这个事情说清楚，本文主要从原理的角度讲解，让你了解这种方式运作的流程，下一篇从实战的角度手把手教你登录ssh服务器。
对于开发者来说，也请务必学会使用密钥对方式登录服务器，因为现在很多应用和服务推荐这种方式，比如Github就可以使用密钥对方式连接，AWS默认就禁止口令登录。
网上有很多文章介绍ssh口令登录，但客观的说，很多文章讲错了。
很多人大概是这样理解的，客户端生成一个公开密码学算法的密钥对（注意不是ssh服务器端的密钥对），然后将公钥放到ssh服务器上的 authorized_keys 文件中（潜台词就是你有ssh权限才能操作）。
然后ssh如何登录呢?在连接过程中，会将客户端密钥对的公钥发送给ssh服务器，服务器在 authorized_keys 文件中匹配到这个公钥，就认为登录成功了，其实这个理解是有问题的。
核心的两个问题：
- ssh登录的时候，并不是将公钥发送给ssh服务器，如果是这样，中间人会拿到对应的公钥，从而也能成功控制ssh服务器。
- 密钥对登录方式是完全安全的（目前我的理解），也不会遇到中间人攻击。
知道了这个结论后，我们看看详细的登录验证过程，在《使用wireshark分析ssh口令登录细节》中说过，ssh登录分为两个阶段，不管是哪一种登录验证，第一阶段的过程都是相同的，区别在于第二阶段。
有的同学说，这次你为啥不用wireshark分析了？因为第二阶段的消息传递都是加密保护的，并不能解密出具体的消息格式，这一点和TLS协议非常不同，TLS协议有多种方式可以解密出明文，而SSH协议是不支持的，所以wireshark只能显示密文。
基于这一点，本文就不用wireshark分析了，简单谈一谈ssh密钥对登录的流程，要经过多个消息交互。
第二阶段具体的流程如下：
1：ssh客户端生成一个 key ID（这个ID是基于密钥对的公钥算出来的，具体格式未知），再一次说明，这个密钥对不是服务器的，使用会话密钥加密后发送给服务器端。
2：服务器端从 authorized_keys 文件中匹配 key ID，如果匹配，此时还不能证明这个ssh客户端是真正的客户端密钥对的主人。
3：服务器端生成一个随机数，然后用客户端的公钥加密后发送给客户端。
4：客户端使用自己的私钥解密出服务器端的随机数，注意，如果某个攻击者仅仅有客户端的公钥，它是无法解密出的，因为攻击者没有对应的私钥。
5：为了向服务器端证明它能解密出这个随机数，客户端将解密出的随机数用会话密钥加密，将得到的值进行MD5运算。然后将这个值发送给服务器，以便响应（4）阶段的消息。
6：服务器端对原始随机数也使用会话密钥加密，再进行MD5计算，如果得出的值和（5）阶段客户端发送的一致，代表双方的登录校验通过。
服务器端使用服务器密钥对公钥指纹像客户端证明它就是真正的服务器端；而客户端使用它自己的密钥对向服务器证明它就是真实的客户端。
由于在验证过程中，客户端密钥对的公钥不会传输，所以即使遇到中间人攻击，攻击者也不会获取到公钥（不考虑客户端机器本身遇到攻击了）。
如果客户端的公钥曾经泄漏过，攻击者也不能成功登录ssh服务器，原因是攻击者没有私钥，无法解密出随机数，从而不能完成验证。
当然如果客户端密钥对公钥和私钥全部泄漏了，那就当我什么也没说，所以定期更换密钥对还是有好处的。
基于以上两点，我认为ssh密钥对登录是安全的，也是推荐的。
