SSH HTTPS 公钥秘钥对称加密非对称加密

Posted 2020-10-12 songjy2116

转载：http://blog.csdn.net/a1232345/article/details/44594867

 

公钥、私钥 的解释

公钥 :用于向外发布，任何人都能获取， 
私钥 :要自己保存，切勿给别人

一下两种情况经常有人弄混，一定要理解。

情况1：公钥用于【加密】， 私钥用于【解密】 
如果加密密钥是公开的，这用于客户给私钥所有者上传加密的数据，这被称作为公开密钥加密(狭义)。 
例如，网络银行的客户发给银行网站的账户操作的加密数据。HTTPS 等。

情况2：公钥用于【解密】，私钥用于【加密】 
如果解密密钥是公开的，用私钥加密的信息，可以用公钥对其解密，用于客户验证持有私钥一方发布的数据或文件是完整准确的，接收者由此可知这条信息确实来自于拥有私钥的某人，这被称作数字签名，公钥的形式就是数字证书。例如，从网上下载的安装程序，一般都带有程序制作者的数字签名，可以证明该程序的确是该作者（公司）发布的而不是第三方伪造的且未被篡改过（身份认证/验证）。

refer:

公开密钥加密 - 维基百科，自由的百科全书

数字证书原理

签名：

加密后的hash值 
这里主要解释一下签名，签名就是在信息的后面再加上一段内容，可以证明信息没有被修改过，怎么样可以达到这个效果呢？一般是对信息做一个hash计算得到一个hash值，注意，这个过程是不可逆的，也就是说无法通过hash值得出原来的信息内容。在把信息发送出去时，把这个hash值加密后做为一个签名和信息一起发出去

指纹：

指纹算法 即 一个hash算法 ，例如md5算法； 
注意，为了保证安全，在证书的发布机构发布证书时，证书的指纹和指纹算法，都会加密后再和证书放到一起发布，以防有人修改指纹后伪造相应的数字证书。这里问题又来了，证书的指纹和指纹算法用什么加密呢？他们是用证书发布机构的私钥进行加密的。可以用证书发布机构的公钥对指纹和指纹算法解密，也就是说证书发布机构除了给别人发布证书外，他自己本身也有自己的证书。证书发布机构的证书是哪里来的呢？？？这个证书发布机构的数字证书(一般由他自己生成)在我们的操作系统刚安装好时(例如windows xp等操作系统)，这些证书发布机构的数字证书就已经被微软(或者其它操作系统的开发机构)安装在操作系统中了，微软等公司会根据一些权威安全机构的评估选取一些信誉很好并且通过一定的安全认证的证书发布机构，把这些证书发布机构的证书默认就安装在操作系统里面了，并且设置为操作系统信任的数字证书。这些证书发布机构自己持有与他自己的数字证书对应的私钥，他会用这个私钥加密所有他发布的证书的指纹作为数字签名。

refer: 
数字签名是什么？

---

公钥登陆 error

使用密码登录，每次都必须输入密码，非常麻烦。好在SSH还提供了公钥登录，可以省去输入密码的步骤。 
所谓"公钥登录”，原理很简单，就是用户将自己的公钥储存在远程主机上。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录shell，不再要求密码。 
这种方法要求用户必须提供自己的公钥。如果没有现成的，可以直接用ssh-keygen生成一个：

　　$ ssh-keygen

refer:

SSH原理与运用（一）：远程登录 - 阮一峰的网络日志

localhost：客户端， 
remotehost：服务器 
密钥访问：localhost通过ssh-keygen来生成公钥密钥对，如果他想访问一个remotehost，则只需要将公钥添加到 remotehost的~/.ssh/authorized_keys中，接下来，当localhost通过ssh登录 username@remotehost时，remotehost会生成一个随机数，通过autrorized_keys中的公钥们生成一系列数值发给 localhost，localhost会通过自己的私有密钥解密发过来的一系列数值（当然，只有用对应的公钥生成的数值才会被正常解密），随 后，localhost将解密后的数值发回去，remotehost若发现发回来的数值是原先产生的随机数时，便会允许该localhost访问。当然， 如果localhost生成的rsa密钥是需要密码的话，接下来还要输入该密码。

refer:

ssh 密钥访问

---

SSH基本原理和免密码登录

从客户端来看,SSH提供两种级别的安全验证：

第一种级别是基于口令的安全验证:

（1）远程主机收到用户的登录请求，把自己的公钥发给用户。

（2）用户使用这个公钥，将登录密码加密后，发送回来。

（3）远程主机用自己的私钥，解密登录密码，如果密码正确，就同意用户登录。

缺点：如果有人冒充服务器，就会给你假服务器公钥，最后就能获得你回应的密码，这就是中间人攻击。

第二种级别是基于密匙的安全验证：

前提：客户端创建一对公钥+秘钥，同时将公钥放在服务器上。

1.客户端软件就会向服务器发出请求，请求用你的密匙进行安全验证；

1. 服务器收到请求之后，先在该服务器上寻找你的公钥，然后把它和你发送过来的公用密匙进行比较。如果两个密匙一致，服务器就用这个公钥加密一个【随机字符串】并把它发送给客户端软件； 
   3.客户端软件收到【加密后的-随机字符串】之后，就可以用你的私人密匙解密，再把【随机字符串】发送给服务器

与第一种级别相比，第二种级别不需要在网络上传送口令。第二种级别不仅加密所有传送的数据，而且“中间人”这种攻击方式也是不可能的（因为他没有你的私人密匙）。但是整个登录的过程可能需要10秒，但是相比输入密码的方式来说10秒也不长。

refer:

SSH基本原理和免密码登录

---

公钥认证的原理

所谓的公钥认证，实际上是使用一对加密字符串，一个称为公钥(public key)，任何人都可以看到其内容，用于加密；另一个称为密钥(private key)，只有拥有者才能看到，用于解密。通过公钥加密过的密文使用密钥可以轻松解密，但根据公钥来猜测密钥却十分困难。

ssh 的公钥认证就是使用了这一特性。服务器和客户端都各自拥有自己的公钥和密钥。为了说明方便，以下将使用这些符号。

Ac 客户端公钥 
Bc 客户端密钥 
As 服务器公钥 
Bs 服务器密钥 
在认证之前，客户端需要通过某种方法将公钥 Ac 登录到服务器上。

认证过程分为两个步骤。

会话密钥(session key)生成 
客户端请求连接服务器，服务器将 As 发送给客户端。 
服务器生成会话ID(session id)，设为 p，发送给客户端。 
客户端生成会话密钥(session key)，设为 q，并计算 r = p xor q。 
客户端将 r 用 As 进行加密，结果发送给服务器。 
服务器用 Bs 进行解密，获得 r。 
服务器进行 r xor p 的运算，获得 q。 
至此服务器和客户端都知道了会话密钥q，以后的传输都将被 q 加密。 
认证 
服务器生成随机数 x，并用 Ac 加密后生成结果 S(x)，发送给客户端 
客户端使用 Bc 解密 S(x) 得到 x 
客户端计算 q + x 的 md5 值 n(q+x)，q为上一步得到的会话密钥 
服务器计算 q + x 的 md5 值 m(q+x) 
客户端将 n(q+x) 发送给服务器 
服务器比较 m(q+x) 和 n(q+x)，两者相同则认证成功

refer:

ssh 公钥私钥认证原理

---

非对称加密

• 服务器建立公钥： 每一次启动 sshd 服务时，该服务会主动去找 /etc/ssh/ssh_host* 的文件，若系统刚刚安装完成时，由于没有这些公钥，因此 sshd 会主动去计算出这些需要的公钥，同时也会计算出服务器自己需要的私钥

• 客户端主动联机请求： 若客户端想要联机到 ssh 服务器，则需要使用适当的客户端程序来联机，包括 ssh, putty 等客户端程序连接

• 服务器传送公钥给客户端： 接收到客户端的要求后，服务器便将第一个步骤取得的公钥传送给客户端使用 (此时应是明码传送，反正公钥本来就是给大家使用的)

• 客户端记录并比对服务器的公钥数据及随机计算自己的公私钥： 若客户端第一次连接到此服务器，则会将服务器的公钥记录到客户端的用户家目录内的 ~/.ssh/known_hosts 。若是已经记录过该服务器的公钥，则客户端会去比对此次接收到的与之前的记录是否有差异。若接受此公钥， 则开始计算客户端自己的公私钥

• 回传客户端的公钥到服务器端： 用户将自己的公钥传送给服务器。此时服务器：具有服务器的私钥与客户端的公钥，而客户端则是： 具有服务器的公钥以及客户端自己的私钥，你会看到，在此次联机的服务器与客户端的密钥系统 (公钥+私钥) 并不一样，所以才称为非对称加密系统

• 开始双向加解密： (1)服务器到客户端：服务器传送数据时，拿用户的公钥加密后送出。客户端接收后，用自己的私钥解密 (2)客户端到服务器：客户端传送数据时，拿服务器的公钥加密后送出。服务器接收后，用服务器的私钥解密，这样就能保证通信安全

refer:

SSH 协议与OpenSSH详解 - Share your knowledge … - 51CTO技术博客

---

SSL/TLS协议

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

SSL/TLS协议(HTTPS 也是这样的)的基本过程是这样的:

1.客户端生成【随机数1】，客户端（通常是浏览器）先向服务器发出加密通信的请求，发送【随机数1】，向服务器端索要公钥；  
2.服务器收到客户端请求后，生成【随机数2】，向客户端发出回应，回应信息包括【随机数2】，服务器证书(包含公钥)  
3.客户端收到后，验证服务器证书的有效性，取出公钥，生成【随机数3】，使用公钥加密【随机数3】，发给服务器。  
4.服务器回应， 至此，服务器和客户端都有3个随机数，使用3个随机数生成这次的会话秘钥(即对称秘钥)，二者开始使用对称加密通讯。服务器通知客户端：编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验(对称加密)。
5.之后二者将通过对称加密来通讯。

解释：为啥使用3个随机数。

不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性，三个随机数通过一个密钥导出器最终导出一个对称密钥，增加随机性

之前很多讲HTTPS原理的(包括下面的https)，都只有1个随机数，为啥？因为毕竟是讲原理，并没有讲清细节； 
简单来说，一开始使用的非对称加密，就是为了安全的传递对称秘钥，毕竟对称加密的速度快。

refer:

SSL/TLS协议运行机制的概述