ssh的发展历程与基本原理

最新推荐文章于 2024-06-19 09:37:05 发布

weixin_30716141

最新推荐文章于 2024-06-19 09:37:05 发布

阅读量364

点赞数

文章标签：运维 shell 密码学

原文链接：http://www.cnblogs.com/harrymore/p/8627345.html

版权

一、ssh是什么

SSH（Secure Shell）是一个提供数据通信安全、远程登录、远程指令执行等功能的安全网络协议，最初提出目的是替代非安全的Telnet、rsh、rexec等远程Shell协议。之后SSH发展了两个大版本SSH-1和SSH-2。

二、ssh的发展历史

1. 1.x版本

1995年，芬兰赫尔辛基理工大学的研究员Tatu Ylönen设计了ssh协议的第一个版本（现称SSH-1），目标是取代早期的rlogin, TELNET, ftp和rsh这些不安全的协议。同年七月，他以免费软件的形式发布了这个协议的一个实现，并迅速流行起来。

1995年12月，Ylonen创建了SSH Communications Security来发展和商业化SSH，SSH软件的原始版本使用了各种免费软件，如Gun libgmp，但是后来由SSH Communications Security发布的版本逐渐演化为私有软件。

2. 2.x版本

“Secsh”，IETF工作小组的官方互联网工程任务组，负责SSH协议的第二版本。在2006年，他们发布了SSH协议修订版，即SSH-2，并被采纳为标准。该版本与SSH-1不兼容，但在安全性和特性方面都优于SSH-1。更好的安全性，例如，通过Diffie-Hellman密钥交换和通过信息认证码进行强大的完整性检查。SSH-2的新特性，增加了在单个SSH连接上运行任意数量的shell会话的能力。由于SSH-2比SSH-1更有优势而且受欢迎，一些实现如Lsh和Dropbear仅支持SSH-2协议。

3. 1.99版本

在2006年1月，在2.1版本建立之后，RFC 4253指定一个支持ssh2.0以及兼容之前版本的SSH服务的协议版本为1.99。这不是一个实际的版本，而是一种识别向后兼容性的方法。

4. OpenSSH and OSSH

早在1999年，很多开发人员都很想要一个可用的免费版本，他们找到了SSH源程序的1.2.12发布版本，这是它在开放源码许可下发布的最后一个版本，Bjorn Gronvall的OSSH就是后来以这个为基础发展出来的。不久，OpenBSD开发人员在Gronvall的代码的基础上开了一个分支，并对其进行了大量的工作后，创建了OpenSSH，这是由2.6版本的OpenBSD发布的。在这个版本中，一个“可移植性”分支被创建了，目的是让OpenSSH能在其他操作系统中使用。

到了2005年，OpenSSH已经是最流行的SSH实现了，没有之一，在很多操作系统中都默认安装OpenSSH。与此同时，OSSH却过时了。OpenSSH一直在维护并支持SSH-2协议，在7.6版本的OpenSSH代码库中，去除了对SSH-1的支持。

三、ssh的主要特性

1. 加密

避免数据内容泄漏

2. 通信的完整性

避免数据被篡改，以及发送或接受地址伪装（检查数据是否被篡改，数据是否来自发送者而非攻击者） SSH-2 通过 MD5 和 SHA-1 实现该功能，SSH-1 使用 CRC-32

3. 认证

识别数据发送者和接收者身份客户端验证SSH服务端的身份：防止攻击者仿冒SSH服务端身份，避免中间人攻击和重定向请求的攻击；OpenSSH 通过在 know-hosts 中存储主机名和 host key 对服务端身份进行认证服务端验证请求者身份：提供安全性较弱的用户密码方式，和安全性更强的 per-user public-key signatures；此外SSH还支持与第三方安全服务系统的集成，如 Kerberos等

4. 授权

用户访问控制

5. 转发

可以通过SSH为Telnet、FTP等提供通信安全保障，支持三种类型的转发操作：Port Forwarding，X Forwarding，Agent Forwarding

四、ssh基本框架

SSH协议框架中最主要的部分是三个协议：

传输层协议（The Transport Layer Protocol）提供服务器认证，数据机密性，信息完整性等的支持；
用户认证协议（The User Authentication Protocol）则为服务器提供客户端的身份鉴别；
连接协议（The Connection Protocol）将加密的信息隧道复用成若干个逻辑通道，提供给更高层的应用协议使用；各种高层应用协议可以相对地独立于SSH基本体系之外，并依靠这个基本框架，通过连接协议使用SSH的安全机制。

同时SSH协议框架中还为许多高层的网络安全应用协议提供扩展的支持。它们之间的层次关系可以用如下图来表示：

五、ssh的加密

1. ssh加密方式

SSH从安全和性能两方面综合考虑，结合使用了 Public Key/Private key（公钥/私钥）和 Secret Key（密钥）。

Public Key/Private key：非对称加密，安全，但效率低，不适合大规模进行数据的加密和解密操作
Secret Key：对称机密，高效，但安全性相对较低，Key的分发尤其不方便

对密码学基础知识和数字签名了解，可以参考阮一峰的博文

2. ssh中的key

名称	生命周期	创建	类型	描述
Host Key	持久化	服务端	Public Key	Host Key是服务器用来证明自己身份的一个永久性的非对称密钥
User Key	持久化	用户	Public Key	User Key 是客户端用来证明用户身份的一个永久性的非对称密钥（一个用户可以有多个密钥/身份标识）
Server Key	默认为1小时	服务端	Public Key	Server Key 是SSH-1协议中使用的一个临时的非对称密钥，每隔一定的间隔（默认是一个小时）都会在服务器重新生成。用于对Session Key进行加密（仅SSH-1协议有，SSH-2对其进行了增强，这里Server Key作为一个概念便于在流程中进行描述）
Session Key	客户端	会话（Session）	Secret Key	Session Key是一个随机生成的对称密钥，用户SSH客户端和服务器之间的通信进行加密，会话结束时，被销毁

ssh框架图：

六、安全连接的建立过程

SSH处理过程可以分解成几个主要阶段：

协议协商阶段
服务端认证阶段
客户端认证阶段
数据传输阶段

每个阶段均涉及到客户端与服务端的多次交互，通过这些交互过程完成包括证书传输、算法协商、通道加密等过程。

1. 协议协商阶段

1）服务端打开服务端口（默认为22），等待客户端连接

2）客户端发起TCP连接请求，服务端接收到该请求后，向客户端发送包括SSH协议版本信息

3）客户端接根据该版本信息与自己的版本，决定将要使用的SSH版本，并向服务端发送选用的SSH版本信息

4）服务端检查是否支持客户端的决定使用的SSH版本

至此，双方完成协议协商。如果该过程中，客户端或服务端发送SSH版本无法兼容，任何一方都可以断开连接。

2. 服务端认证阶段

完成协议协商阶段后，客户端与服务端已经建立明文的通信通道，之后进入服务端认证阶段。

SSH协议中没有明确的服务端认证过程，而通过一系列的服务端与客户端的交互来确定服务端的身份，该过程还会完成Host Key、User Key、Session Key等在客户端与服务端之间的传输。

1）建立连接后，服务端向客户端发送：

Host Key：用于认证服务端的身份
Server Key：用于帮助建立安全的数据传输通道
8字节的随机数，即检测字节（check bytes)：客户端通过在下一次响应中包含该随机数，防止IP地址欺诈
服务端支持的加密算法、压缩方式和认证方式

这个时候，客户端和服务端使用Host Key、Server Key和检测字节生成一个128位的MD5值，作为此次会话的session id。

2）客户端在接收到服务端Host Key后，会检查自己的knows host数据库中（一般为~/.ssh/know_hosts文件），是否已经包含当前服务端的Host Key，如果有则继续下一步；如果没有或包含当前服务端的其他Host Key，则由用户决定是否信任该服务端，或终止当前连接。

The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?

如果客户端拒绝接受这个主机密钥，那么连接就中止了。否则，继续。

3）客户端向服务端发送session Key

出于性能考虑，SSH采用对称加密（Secret Key），对实际通信内容进行加密，即Session Key。因此Session Key的安全尤为重要，一旦Session Key泄漏给攻击者，那所有的通信数据都可能被攻击者截获。由于当前通道还是采用明文方式，客户端采用Host Key和Server Key对Session Key进行两次加密来加强安全性，同时还会发送检测字节和所选定的算法(这些算法是从第1步中服务器支持的算法列表中挑选出来的）。

4）服务端得到Session Key后，客户端和服务端就可以通过Session Key对数据进行加密解密操作，到此，双方完成安全（加密）通道的建立。 Host Key和Server Key都是Public Key（非对称加密），只有通过服务端的私钥（Private Key）才能对其解密，以得到Session Key。在正式使用安全通道前，客户端要求服务端发送使用Session Key加密的确认信息，以验证服务端的身份。为避免Session Key的泄漏，SSH还采取了其他安全措施，Session Key仅保存在内存避免其泄漏；周期性更换Server Key，默认为1小时（SSH 2对Server Key安全进一步增强）。

3. 客户端认证阶段

SSH提供多种客户端认证方式。

SSH-1：

Password
Public Key
Kerberos
Rhosts && RhostsRSA
TIS

SSH-2：

Password
Public Key
hostbased 在SSH-2中考虑Rhosts存在安全漏洞，废弃了这种方式。

这里之讨论我们经常使用的的Password和Public Key方式。

此时安全通道已经及建立，之后的所有内容都通过Session Key加密后进行传输。

1）Password

Password 方式既客户端提供用户和密码，服务端对用户和密码进行匹配，完成认证。类Unix系统中，如 OpenSSH 的框架，一般通过系统的本地接口完成认证。

Password 的优势是简单，无需任何而外的配置就可以使用。缺点密码不便于记忆，过于简单的密码容易被暴力破解。

2）Public Key

Public Key认证的基本原理是基于非对称加密方式，分别在服务端对一段数据通过公钥进行加密，如果客户端能够证明其可以使用私钥对这段数据进行解密，则可以说明客户端的身份。因为服务端需要使用客户端生成的密钥对的公钥对数据首先加密，所以需要先将公钥存储到服务端的密钥库（Auhtorized Key）。还记得Github中使用git协议push代码前需要先添加SSH KEY吗？

下面详细介绍一个通过Public Key进行客户端认证的过程。

1）客户端发起一个Public Key的认证请求，并发送RSA Key的模数作为标识符。（如果想深入了解RSA Key详细 --> 维基百科）

2）服务端检查是否存在请求帐号的公钥（Linux中存储在~/.ssh/authorized_keys文件中），以及其拥有的访问权限。如果没有则断开连接

3）服务端使用对应的公钥对一个随机的256位的字符串进行加密，并发送给客户端

4）客户端使用私钥对字符串进行解密，并将其结合session id生成一个MD5值发送给服务端。结合session id的目的是为了避免攻击者采用重放攻击（replay attack）。

5）服务端采用同样的方式生成MD5值与客户端返回的MD5值进行比较，完成对客户端的认证。