注意：本文相关配置及说明已在 CentOS 6.5 64 位操作系统中进行过测试。其它类型及版本操作系统配置可能有所差异，具体情况请参阅相应操作系统官方文档。

SSH 服务在进行数据传输前，会先进行密钥交换和协商确认。完成后再对后续数据进行加密传输，以提高安全性。本文先对 SSH 服务所采用的非对称加密技术进行简要介绍，然后对 SSH 连接过程中的相关交互，及关联文件进行说明。

非对称加密技术 SSH 服务基于非对称加密（public-key cryptography，也称公开密钥加密）技术实现数据加密传输。该技术会生成一对数学相关的密钥，其中一个用于对数据进行加密，而且只能用于加密，而另一个只能用于解密。使用加密密钥加密后的数据，只能用对应的解密密钥才能解密。而且，只知道其中一个密钥，无法计算出另一个。因此，如果公开了一对密钥中的一个，并不会危害到另一个的秘密性质。通常把公开的密钥称为公钥（public key），而不公开的密钥称为私钥（private key）。

如果公开的是解密密钥，该场景用于客户端验证持有私钥一方发布的数据或文件的完整性、准确性，以防止数据篡改。相应的密钥称为数字签名（数字证书）。如果公开的是加密密钥，该场景用于客户给私钥所有者上传数据，称为公开密钥加密。 SSH 服务基于该场景实现。

与对称密钥加密相比，非对称加密的优点在于不存在共享的通用密钥。由于解密用的私钥无需发送给任何用户，所以可以避免密钥被劫持或篡改。而加密用的公钥即便被劫持或篡改，如果没有与其匹配的私钥，也无法解密数据。所以，截获的公钥是没有任何用处的。

当前，SSH主要采用 RSA 算法（协议 V2 默认算法）和 DSA 算法（协议 V1 仅支持该算法）来实现非对称加密技术。

连接交互过程 SSH 服务建立连接时的相关交互过程，如下SSH 服务连接交互示意图 所示：

连接过程中的相关交互步骤，详细说明如下。

服务端准备阶段 非对称加密协商 后续数据交互过程 服务端准备阶段 服务端在每次启动 SSH 服务时，都会自动检查 /etc/ssh/ 目录下相关密钥文件的有效性。如果相关文件检查发现异常，则会导致服务启动失败，并抛出相应错误信息。 如果文件相关不存在，则会自动重新创建。

默认创建的相关文件及用途说明如下：

ll /etc/ssh/ -rw-------. 1 root root 125811 Aug 13 2015 moduli → 用于 DH-GEX 算法 -rw-r--r--. 1 root root 2047 Aug 13 2015 ssh_config → SSH 客户端配置文件 -rw-------. 1 root root 3879 Aug 13 2015 sshd_config → SSH 服务配置文件 -rw-------. 1 root root 672 May 20 14:22 ssh_host_dsa_key → DSA 算法私钥 -rw-r--r--. 1 root root 590 May 20 14:22 ssh_host_dsa_key.pub → DSA 算法公钥 -rw-------. 1 root root 963 May 20 14:22 ssh_host_key → SSH V1 版RSA 算法私钥 -rw-r--r--. 1 root root 627 May 20 14:22 ssh_host_key.pub → SSH V1 版 RSA 算法公钥 -rw-------. 1 root root 1675 May 20 14:22 ssh_host_rsa_key → SSH V2 版 RSA 算法私钥 -rw-r--r--. 1 root root 382 May 20 14:22 ssh_host_rsa_key.pub → SSH V2 版 RSA 算法公钥 非对称加密协商 服务端 SSH 服务正常运行后，客户端连接时，进行如下交互：

客户端向服务端发送连接请求。 客户端通过 SSH 工具连接服务端。相关信息通过明文发送。 服务端返回公钥信息： 根据客户端所使用的服务协议版本及算法设置，返回相应公钥信息。比如，默认情况下，客户端通过 SSH V2 版协议，基于 RSA 算法建立连接，则服务端将 ssh_host_rsa_key.pub 文件中的内容返回客户端。相关信息通过明文发送。 客户端对服务端公钥信息进行比对和确认： 客户端接收到服务端公钥信息后，会进行如下比对，并让用户对相关信息进行确认。 如果是首次连接服务端，客户端会收到类似如下信息，让用户确认公钥指纹的有效性： The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established. RSA key fingerprint is c2:49:d9:43:74:d5:ed:bc:28:9b:d2:7b:63:94:cf:bc. Are you sure you want to continue connecting (yes/no)?

<ol>
	<li class="MsoListParagraph"><span>如果用户输入</span><span> <span>no </span></span><span>，则连接中断并报错（</span><span>Host key verification failed</span><span>）。</span></li>
</ol>

<ul>
	<li class="MsoListParagraph"><span>如果用户输入</span><span> <span>yes</span></span><span>，则会将相应的公钥信息，保存到当前用户家目录下</span><span> .ssh </span><span>目录内的</span><span> <span>known_hosts </span></span><span>文件中。</span><span> </span><span>比如：</span>

cat ~/.ssh/known_hosts

IP 明文显示： 192.168.0.1 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3sdlboGEgY9buZpkPuygPw0NxAvmxYd0mc3fo2MgP+JqgFC9/9ZXOgDXKJrjE2HKBieJZSPKGncIh+zLxTvmykeJQBXv7i1GiUjW+H3VY69Ge3AdGfCd+XF+Cvi1e+j18zhHnjSzvIBoNpT5cBWWNbw7mNHCwTb0sHAVUkWR4Ck/LM5/rQ09A+m6BLfZJL8CRNGxKTbyINi6o812S+Cy64WqDs1nTpIXp2Bkcpjclb36bFSs9Z/tWNuJl7A//7HNtxMgFGBnE07Ykvvy8s06DUmkyFy8GcXGBpnfdg9utLodfQLFQnKflCQZ110BpQaCWlWPjU9dc4w3XLJ/XQOP4w==

IP 做了加密处理： |1|3efXAZ4sNHcUcHamBy4gDriblc8=|8idBhLq9aLl2sfh4KswMsk4sPFI= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwS4DE3hok8RCkxYlTxsexNrNa62e05UGSkoP7ie26DDWjG1Aoc74cCsE4is9p7lEfFUYYlAzeYhPqE/yGf5YxRZUOU2IeFI4cEqo8YZr7edVYpgAq2f2J0zMwk1syenD12lmUPkYA4mMB6it3jxXR5k+H0HZh9YA7mRXkiTjlkAMWirBcnUvtKYRv9LRIr3ikUiPy2gfZO291Ae9zuTsWwEtHQxIpiBgk3vwF2gCUFlX9y//IsMjdQq5prk7x3BjXhUorqgJO1gt1VHW8Xxx9Oe50YF1hi9DuE6VXwyh4xfHTmauRQybwsYafdA3HxrA2od6x9l19D9EH7xHAjDa5w== 如果服务端因重装系统等因素导致公钥指纹出现变化，则会直接导致连接失败（报错Host key verification failed），则需要删除已保存的条目后再重新连接。 相关操作可以参阅 云服务器 ECS Linux 客户端 SSH 公钥指纹不匹配导致 SSH 登录失败。 如果之前已经成功连接，而且公钥指纹对比一致，则会继续下一步操作。 客户端生成临时密钥对： 服务端公钥校验及确认后，客户端会生成一对临时密钥用于客户端加密。该密钥对不会存储到文件，而是记录在内存中。每次连接都会重新生成临时密钥对。

客户端发送公钥信息： 客户端向服务端，发送前述生成的临时密钥对中的公钥信息。相关信息通过明文发送。

至此，服务端及客户端都拥有对方的公钥和自身的私钥，所以称为非对称加密。

后续数据交互过程

后续登录校验及正常的数据传输，都会通过双向加密方式进行。相关交互说明如下：

如果服务端需要发送数据给客户端：

• 服务端使用所持有的客户端公钥，对需要传输的数据进行加密，再发送给客户端。
• 客户端收到信息后，使用所持有的自身私钥解密后获取数据。