前言：

本来感觉对ssh登录的原理有所了解，无非就是有个公私钥对，利用公私钥对进行加解密来实现传输的安全，但仔细想具体的过程，就感觉对细节把握就不是那么明确了。

查找资料：

然后就在网上翻相关的介绍，发现有好多资料是这样的说法：

（1）远程主机收到用户的登录请求，把自己的公钥发给用户。
（2）用户使用这个公钥，将登录密码加密后，发送回来。
（3）远程主机用自己的私钥，解密登录密码，如果密码正确，就同意用户登录。

看完之后，感觉挺简单的，但仔细一想这好像说的太简单了，为什么没有说明，登录成功后的传输是怎么加密的。https我是知道是建立连接后通过对称加密传输的，以减少cpu的消耗，我想ssh应该也是这样的。然后就继续寻找确切的答案。这里我找到我认为需要的答案。摘抄上面的一段话.

1）在主机A上向主机B发送连接请求；
2）主机B在与用户建立连接后，把自己的公钥发送给主机A；
3）主机A通过密钥协商技术产生一个随机密钥，然后使用主机B的公钥对这个随机密钥进行加密后发送给主机B;
4） 主机B接收到主机A发送过来的密文形式的密钥后，通过自己的私钥进行解密，得到对称加密使用的密钥明文；至此，会话密钥已经生成完毕了；
5）主机A通过生成的会话密钥对账号和密码等信息进行加密然后发送给主机B；
6）主机B接收到加密信息后，使用会话密钥进行解密，从而得到明文的账号和密码进行账号验证；
7）主机B在验证账号和密码后通知主机A是否登录成功；

其实，进行账号密码登录的时候不是通过公钥加密，私钥解密的形式的。公私钥的应用是在建立连接生成会话密钥的时候用到的，通过公私钥协商的密钥可以保证不会被第三方知道，而保证当前的会话不会被窃取(此时会话已经使用了对称加密)，之后进行服务器账号密码登录。使用这种非对称加密也减轻了服务器的负担。
其中，还有一点注意的是，服务器发送公钥给客户端的时候，怎么判断是不是服务器发的，有没有中间人攻击的可能，当然我们https是可以通过根证书解决这个问题的。但是ssh端就需要靠用户自己了，我们每次登录新机器的时候显示:

auth.png

前言：从上次小红给小李写过情书之后，已经变了亲密的情侣，之后小李要和小红说悄悄话，当然这些不想让别人听到。该怎么办呢？
前提：小红已经接受了小李，所以已经给了小李说悄悄话的通行证，就是账号和密码，且小李一直保存着小红的公钥,以备说悄悄话的时候使用。
1.小李先用公钥加密了我要和你说悄悄话的消息，并附带了我们之后说话的密钥，发给了小红。
2.小红收到了消息，解密了消息，发现是要和自己说悄悄话，脸红了一下，不过没事，只有小红有这个私钥，其他人拿到这个消息也不知道是什么内容。小红想到这里，很坦然。不过悄悄话哪能随便跟别人说的，先要问问对方是不是自己的正牌男友。
3.于是小红用小李给的会话密钥加密了想和我说悄悄话可以，但是你要证明你是我男朋友发给了小李。
3.小李收到了小红发来的消息，起初也有担心，这个消息会不会不是小红发的，是情敌为了获取自己和小红的悄悄话暗号伪装小红来发的，不过用自己发给小红的密钥成功解密了，就放心了，因为小李确定只有小红才有他刚才加密信息的公钥的私钥。
4.然后小李的放心的用会话密钥加密了账号密码发给了小红。
5.小红收到后用相同的密钥进行了解密，比对了账号密码，确定了就是小李，然后告诉小李你已经通过了我的考验,开始说悄悄话吧。但是一定要用我们协商好的密钥加密才行。
6.小李收到后，很开心，然后和小红快乐的在说悄悄话。

注：

小红和小李之后的说话为什么不用公私钥对进行加密?

• 那样说话太慢了，解密对方说的话话时间，影响说话的体验，而且还费脑子

小红和小李会一直用这个协商的密钥吗?

• 人家才没那么傻，隔一段时间人家会再协商个新的密钥进行加密对话。

以后人家更亲密了，悄悄话频率更高了，要升级安全了怎么办?

• 小李自己也搞了对公私钥，并让小红信任了自己的公钥，之后就可以参考密钥登录了，这里就不细说了。原理其实举一反三。

结语：

其实ssh和https的原理类似，但是https多了一个根证书的功能，就是各个https站点的公私私钥是这些根证书信任的机构颁发的，然后浏览器内置了这些证书颁发机构的公钥，然后就可以从颁发机构那里确定我们得到的公钥是不是我们要访问的服务器的公钥。解决了第一步信任的问题。
--
另外对于某些政府网站https证书不信任的问题，我对此的理解是，我们政府不会托管自己的公私钥对给证书颁发机构，因为政府的信息都是私密性的，不希望被其他人特别是根证书机构的国外窃听到。

最后上面内容是自己基于此的拙解，如果有错误的地方，望指出。谢谢了。