这篇文章给大家分享的是有关Linux系统中SSH服务基于key认证实践的示例分析的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
众所周知ssh是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议，它默认工作在tcp的22号端口，具体实现的软件有：openssh（centos默认安装的），dropbear。ssh协议目前有两个版本v1和v2，v1基于CRC-32做MAC,不安全。v2基于DH算法做密钥交换，基于RSA或DSA实现身份认证。所以目前大多流行的Linux都是使用的V2版本。
简单了解了下ssh，我们再来说说它的两种用户登录认证方式，第一种基于用户名口令的方式，这种认证方式想必大家都应该知道，就是我们要想登录远端Linux系统，我们必须要输入相应的用户名口令才可以登录到远程Linux系统，这种方式是交互式方式登录。第二种就是我们今天要说的基于key的认证方式。
首先我们来了解下ssh加密通讯的过程
从上图可以看到，客户端上必须存在一对密钥对，我们都知道密钥是成对出现，况且用A的公钥加密只有A的私钥才可以解密。正是因为非对称加密的这个特性，我们不难理解ssh通信也是利用这个特性来确定数据安全的。在服务端也有一对公钥和私钥，它存在的目的也是为了加密和解密数据。ssh加密通讯的流程大致上这样的，客户端要和服务端加密通信，首先客户端需要拿到服务端的公钥，拿到服务端的公钥后，就可以用服务端的公钥对要发送到数据加密，然后发送到服务端，服务端收到这个密文的数据，它会用自己的私钥去解密，从而实现了客户端到服务端的数据加密。同理服务端要把数据发送给客户端也是一样的过程，拿到客户端的公钥用客户端的公钥加密，然后发给客户端，客户端用自己的私钥解密，从而实现了你来我往的加密通讯。
我们想一下，服务端和客户端通讯都是用对方的公钥来加密数据，那么客户端是怎么拿到服务端的公钥的呢？服务端又是怎么样拿到客户端的公钥的呢？
来看一下服务端和客户端在第一次连接的时候，公钥交换的过程
首先客户端向服务端发送ssh连接请求，服务端收到请求后，会把自己的公钥和会话ID 一并发送给客户端，客户端收到服务器发来的公钥后，它又把自己的公钥和服务器发送过来的会话ID 做异或运算，把得到的结果用服务端的公钥来加密，然后把加密后的密文通过网络发送给服务端，服务端收到客户端发送过来的密文后，它会用自己的私钥去解密，然后把得到的结果和之前的会话ID做异或计算，最终得到客户端的公钥。这样的一个过程后，客户端就拥有了服务端的公钥，服务端也拥有了客户端的公钥，有了对方的公钥后，后续就可以用对方的公钥来加密数据。
使用过Linux的人都知道，在我们第一次和服务器建立ssh远程连接的时候，会有一个确认，问我们是否继续连接，我们输入yes后才能输入密码，这是我为什么呢？其实在服务端发送自己的公钥到客户端的时候，因为客户端没有办法确认它收到的公钥是不是对方服务器发送过来的，它就会把收到的公钥做md5和sha256，提取出公钥的指纹，然后提示我们说我收到了一份md5为xxx的公钥，请问你确认这个公钥吗？如果我们确认，就表示相信这个公钥是服务器发送过来的，这样一来才可以有下面的，把自己的公钥和会话ID做异或运算，把结果用刚才收到的公钥加密。我们想象，如果不是服务器发过来的公钥，而是黑客发送过来的公钥，如果我们确认了，后续的密文黑客拿到后，黑客就以用自己的私钥来解密，得到客户端的公钥和数据，然后他得到真正的数据后，黑客可以任意改动，然后再用服务器的公钥加密，发送给服务端，这样一来服务端得到的数据就是黑客修改后的数据，不是真正客户端发送的数据。这就是所谓的中间人攻击，它是利用自己的公钥来回冒充服务端和客户端角色。
了解了ssh加密通讯的过程和密钥交换的过程，我们再来看看，ssh基于用户名口令和密钥登录验证的过程。
