UNIT08 Secure SHell Protocol

08.1 SSH Protocol Overall

一、SSH Introduction

1Background

         SSH由IETF的Network Working Group所制定。最初的SSH协议是由芬兰的一家公司的研究员Tatu Ylnen于1995年设计开发的,但是因为受版权和加密算法等等的限制,现在很多人都转而使用OpenSSH。OpenSSH是SSH的替代软件包,而且是开放源代码和免费的。

SSH协议是为了克服Telnet协议存在的问题而诞生的。网络中另外一个广泛应用的协议——FTP,也面临着和Telnet相同的问题。为了解决FTP应用中的安全性问题,在SSH协议基础上扩展了对FTP安全性的支持,即SFTP。

SSH有很多功能,它既可以代替Telnet,又可以为FTP、POP、甚至为PPP提供一个安全的“通道”。

2、SSH比以前在网络设备管理上广泛应用的Telnet有以下优点:

数据传输采用密文的方式,保证信息交互的机密性;

用户的认证信息以密文的方式传输,可以有效地防止用户信息被窃听;

除了传统的密码认证,SSH 服务器还可以采用多种方式对用户进行认证(如安全性级别更高的公钥认证),提高了用户认证的强度;

客户端和服务器端之间通信使用的加解密密钥,都是通过密钥交互过程动态生成的,可以防止对加解密密钥的暴力猜测,安全性级别比手工配置密钥的方式高;

为客户端提供了认证服务器的功能,可以防止“伪服务器欺骗”。

SSH为其传输的数据压缩可以加快传输的速度。

二、SSH总体框架

SSH协议采用客户端/服务器架构,分为传输层、认证层和连接层。

1、传输层协议(The Transport Layer Protocol

     传输层协议主要用来在客户端和服务器之间建立一条安全的加密通道,为用户认证、数据交互等对数据传输安全性要求较高的阶段提供足够的机密性保护。传输层提供了如下功能:

数据真实性检查

数据完整性检查

为客户端提供了对服务器进行认证的功能

     传输层协议通常运行在TCP/IP连接之上(服务器端使用的知名端口号为22),也可运行在其他任何可以信赖的数据连接之上。

2、用户认证层协议(The User Authentication Protocol

     运行在传输层协议之上,完成服务器对登录用户的认证。

3、连接层协议(The Connection Protocol

     连接层协议负责在加密通道上划分出若干逻辑通道,提供给更高层的应用协议使用。它运行在认证层协议之上,提供交互会话、远程命令执行等服务。

三、SSH安全机制1:保证数据传输的机密性

     SSH协议需要解决Telnet协议明文传输的缺陷,它通过以下两方面保证数据传输的机密性:

1、用加密通道(DES、3DES、AES等对称加密)保证数据不被窃听

2、用密钥交换算法保证密钥本身的安全

     利用密钥交换算法可以在通信双方动态地产生密钥,这个密钥只能被通信的双方获得,任何第三者都无法窃听,这就在源头保证了加解密使用密钥的安全性,很好地解决了对称密钥分发问题。

     密钥交换算法具有如下优势:

扩展性更好,不需要网络管理员的多余配置;

交换得到的密钥是保存在内存中,不易被读取和篡改;

每个连接都会动态生成一次新的密钥,安全性更高。

四、SSH安全机制2:完善的用户认证机制

1、密码认证(分散认证/集中认证)

     第一种级别:基于密码的安全验证),知道帐号和密码,就可以登录到远程主机,并且所有传输的数据都会被加密。但是,可能会有别的服务器在冒充真正的服务器,无法避免被“中间人”攻击。

         在此方案中,服务器主机将自己的公用密钥分发给相关的客户端,客户端在访问主机时则使用该主机的公开密钥来加密数据,主机则使用自己的私有密钥来解密数据,从而实现主机密钥认证,确定客户端的可靠身份。

2、公钥认证(“U盾”)

         第二种级别:基于密匙的安全验证,你必须为自己创建一对密匙,并把公有密匙放在需要访问的服务器上。客户端软件会向服务器发出请求,请求用你的密匙进行安全验证。服务器收到请求之后,先在你在该服务器的用户根目录下寻找你的公有密匙,然后把它和你发送过来的公有密匙进行比较。如果两个密匙一致,服务器就用公有密匙加密“质询”(challenge)并把它发送给客户端软件。从而避免被“中间人”攻击。

     在此方案中,存在一个密钥认证中心,所有提供服务的主机都将自己的公开密钥提交给认证中心,而任何作为客户端的主机则只要保存一份认证中心的公开密钥就可以了。在这种模式下,客户端必须访问认证中心然后才能访问服务器主机。

①目前,设备上可以利用RSA和DSA两种非对称密钥算法实现公钥认证。公钥认证的过程分为两个部分:

公钥验证:客户端首先将自己本地密钥对的公钥部分,按照字符串格式发送到服务器。服务器使用本地保存的客户端公钥,与报文中携带的客户端公钥进行比较,验证客户端持有公钥的正确性。

数字签名验证:如果公钥验证成功,客户端继续使用自己本地密钥对的私钥部分,对特定报文进行摘要运算,将所得的结果(即数字签名)发送给服务器,向服务器证明自己的身份;服务器使用预先配置的该用户的公钥,对客户端发送过来的数字签名进行验证。

     公钥验证和数字签名验证中任何一个验证失败,都会导致本次公钥认证失败。

②公钥认证具有以下特点:

认证强度高,不易受到“暴力猜测”等攻击方式的影响。

有较高易用性。一次配置成功后,后续认证过程自动完成,不需用户记忆和输入密码。

 

08.2 SSH WorkFlow

1、连接建立

SSH服务器端在22端口侦听客户端的连接请求,接收到客户端的连接建立请求后,与客户端进行三次握手,建立起一条TCP连接,后续的所有报文交互都在这个TCP连接之上进行。

2、版本协商(两个不兼容的版本分别是:1.x和2.x)

     TCP连接建立之后,服务器和客户端都会向对端发送自己支持的版本号。服务器端和客户端收到对端发送过来的版本后,与本端的版本号进行比较,双方都支持的最高版本号即为协商出的版本号。版本协商成功后,进入下一个阶段,即算法协商阶段。否则,中断连接。

3、算法协商

①客户端和服务器端都将自己支持的算法列表发送给对方;

② 双方依次协商每一种算法(密钥交换算法、加密算法等),每种算法的协商过程均为:从客户端的算法列表中依次取出一个算法,在服务器端的列表中查找相应的算法,如果匹配上相同的算法,则该算法协商成功,直到匹配成功。

③某一种算法协商成功后,继续按照上述方法协商其他的算法,直到所有算法都协商成功;如果某一种算法协商失败,则客户端和服务器之间的算法协商失败,服务器断开与客户端的连接。

4、密钥交换

加密算法协商成功后,为了保证加解密密钥的安全性,SSH利用密钥交换算法在通信双方安全动态地生成和交互数据的加解密密钥,并能够有效防止第三方窃听加解密密钥。

5、用户认证

Username:root

Password:redhat

①客户端向服务器端发送认证请求报文,其中携带的认证方式为“none”。

②服务器收到none 方式认证请求,回复认证挑战报文,其中携带服务器支持、且需要该用户完成的认证方式列表。

③客户端从服务器发送给自己的认证方式列表中选择某种认证方式,向服务器发起认证请求,认证请求中包含:

密码认证方式中,内容为用户的密码;

公钥认证方式中,内容为用户本地密钥对的公钥部分(公钥验证阶段)或者数字签名(数字签名验证阶段)。

④服务器接收到客户端的认证请求,验证客户端的认证信息:

密码认证方式:服务器将客户端发送的用户名和密码信息,与设备上或者远程认证服务器上保存的用户名和密码进行比较,从而判断认证成功或失败。

公钥认证方式:服务器对公钥进行合法性检查,如果不合法,则认证失败;

     否则,服务器利用数字签名对客户端进行认证,从而判断认证成功或失败。

⑤服务器根据本端上该用户的配置,以及用户认证的完成情况,决定是否需要客户端继续认证,分为以下几种情况:

若该种认证方式认证成功,且该用户不需要继续完成其他认证,则服务器回复认证成功消息,认证过程顺利完成。

若该种认证方式认证成功,但该用户还需继续完成其他认证,则回复认证失败消息,继续向客户端发出认证挑战,在报文中携带服务器需要客户端继续完成的认证方式列表;

若该种认证方式认证失败,用户的认证次数尚未到达认证次数的最大值,服务器继续向客户端发送认证挑战;

若该种认证方式认证失败,且用户的认证次数达到认证次数的最大值,用户认证失败,服务器断开和客户端之间的连接。

     说明:认证挑战是指SSH 服务器将用户需要完成的认证方式列表发送给用户,要求用户从中选择一种,继续发起认证请求。用户未完成认证时,服务器都会通过这种发送认证列表的方式,要求用户进行认证。

6、服务请求

用户成功完成认证后,SSH客户端向服务器端发起服务请求,请求服务器提供某种应用。服务请求的过程为:

客户端发送SSH_MSG_CHANNEL_OPEN 消息,请求与服务器建立会话通道,即session;

服务器端收到SSH_MSG_CHANNEL_OPEN 消息后,如果支持该通道类型,则回复SSH_MSG_CHANNEL_OPEN_CONFIRMATION 消息,从而建立会话通道;

会话通道建立之后,客户端可以申请在通道上进行shell 或subsystem 类型的会话,分别对应SSH 和SFTP 两种类型的服务。

7、数据传输和连接关闭

通信结束或用户空闲时间超时后,关闭会话,断开连接。


 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值