介绍
定义
在配置管理中，终端服务特性提供了设备配置的管理接入接口和交互界面，为用户提供操作场所。
主要包括：
-
Console口登录
-
Telnet Server/Client
-
SSH登录，支持Password、RSA验证、DSA验证
-
支持定制User-interface，提供对登录用户多种方式的认证和授权功能
文件传输特性可以提供系统文件、配置文件的传输控制和文件系统的远程简单管理。
主要包括：
-
FTP Server/Client
-
TFTP Client
-
基于SSH协议的文件传输SFTP Client/Server
-
基于SSL协议的文件传输FTPS Client/Server
本文档将按照协议分类分别介绍各协议特性的原理描述。
主要包括：
-
TFTP协议
-
FTP协议
-
Telnet协议
-
SSH协议
-
SSL协议
-
两阶段生效模式
-
配置回退
目的
终端服务特性提供了设备配置的管理接入接口和交互界面，为用户提供了操作场所。文件传输特性提供了系统文件、配置文件的传输控制和文件系统的远程简单管理功能。
1.2 原理描述
1.2.1 TFTP协议
概述
TFTP（Trivial File Transfer Protocol）即简单文件传送协议。
TFTP客户端模块提供了使用TFTP协议进行文件上传和下载功能，为了实现上的简单，TFTP协议使用UDP协议进行文件的传输。
与FTP相比，TFTP不具有复杂的交互存取接口和认证控制，适用于客户机和服务器之间不需要复杂交互的环境。例如，系统启动时使用TFTP获取系统内存映像。为了保持报文长度短小，TFTP在UDP（User datagram Protocol）基础上实现。
当前设备实现了TFTP客户端功能，没有提供TFTP的服务器端功能。使用TFTP协议的客户端功能可以进行文件上传和下载。
TFTP协议的基本概念
-
操作码
TFTP报文的头2个字节表示操作码，其取值和含义如下：
-
1：Read request RRQ)，表示读请求
-
2：Write request WRQ)，表示写请求
-
3：Data DATA)，表示数据
-
4：Acknowledgment ACK)，表示肯定应答
-
5：Error ERROR)，表示出错
-
-
文件模式
TFTP传输文件有两种模式：
-
二进制模式：用于传输程序文件
-
ASCII码模式：用于传输文本文件
-
目前设备只能使用二进制模式传输文件。
TFTP的基本原理
-
TFTP不提供用户名和口令
因为TFTP初始设计是用于系统引导进程的，所以它不提供用户名和口令。
-
TFTP协议传输
TFTP协议传输由客户端发起。
-
当需要下载文件时，由客户端向TFTP服务器发送读请求包，然后从服务器接收数据包，并向服务器发送确认。
-
当需要上传文件时，由客户端向TFTP服务器发送写请求包，然后向服务器发送数据包，并接收服务器的确认。
-
1.2.2 FTP协议
概述
FTP（File Transfer Protocol）在TCP/IP协议族中属于应用层协议，是文件传输标准。主要功能是向用户提供本地和远程主机之间的文件传输，尤其在进行版本升级、日 志下载和配置保存等业务操作时，广泛地使用FTP功能。FTP协议基于相应的文件系统实现。
FTP采用C/S（Client/Server）结构，如图1-1所示。
图1-1 FTP采用的Client/Server结构
- FTP Server：运行于设备上的FTP服务。提供远程客户端访问和操作的功能，用户可以通过FTP客户端程序登录到设备上，访问设备上的文件。
- FTP Client：FTP的客户端。提供本地设备对远程服务器的文件进行操作的命令。用户在PC上通过终端程序或Telnet程序与作为FTP Client的设备建立连接后，可以输入FTP命令建立与远程FTP Server的连接并访问远程主机上的文件，对远程主机上的文件进行操作。
FTP连接的建立
FTP采用2个TCP连接来传输文件：控制连接和数据连接。其中控制连接用于连接控制端口，传输控制命令；数据连接用于连接数据端口。在控制连接建立后，数据连接通过控制端口的命令建立起连接，进行数据的传输。
FTP连接的建立分为主动模式和被动模式，两者的区别在于数据连接是由服务器发起还是由客户端发起。缺省情况下采用主动模式，用户可以通过命令切换。
主动模式下，当客户端存在防火墙时，由于数据连接是由服务器发起，数据连接可能会发生问题。被动模式下，这个问题得到了解决。主动模式有利于对FTP服务器的管理，不利于对客户端的管理；被动模式则相反。
缺省情况下，服务器的端口21用于传输控制命令，端口20用于传输数据。
主动模式下FTP连接建立
FTP连接主动模式建立过程如图1-2所示。
图1-2 FTP连接主动模式建立过程
- 服务器打开端口21启动监听，等待连接。
- 客户端发起控制连接的建立请求，服务器响应连接，控制连接建立。
- 客户端通过控制连接发送PORT命令，将客户端数据连接的临时端口号告诉服务器。
- 服务器的20号端口与客户端建立起数据连接。
被动模式FTP连接建立
FTP连接被动模式建立过程如图1-3所示。
图1-3 FTP连接被动模式建立过程
- 服务器打开端口21启动监听，等待连接。
- 客户端发起控制连接的建立请求，服务器响应连接，控制连接建立。
- 客户端通过控制连接发送命令字PASV，告知服务器处于被动模式。
- 服务器回应，将服务器数据连接的临时端口号告诉客户端。
- 客户端与服务器的临时端口建立起数据连接。
临时端口为随机产生。
1.2.3 Telnet协议
概述
Telnet（Telecommunication Network Protocol）起源于1969年的ARPANET，是一种最早的Internet应用，Telnet提供了一种通过终端远程登录到服务器的方式，呈现 一个交互式操作界面。用户可以先登录到一台主机，然后再通过Telnet的方式远程登录到网络上的其他主机上去，而不需要为每一台主机都连接一个硬件终 端，然后对设备进行配置和管理。
Telnet协议的基本概念
-
NVT
即网络虚拟终端（Network Virtual Terminal）。是一种双向的虚拟设备，连接的双方都必需把它们各自的物理终端同NVT之间进行转换。Telnet协议可以工作在任何主机（例如，任何操作系统）或任何终端之间正是由于使用了统一的NVT。
NVT是虚拟设备，对于连接的双方，即客户机和服务器，都必须把它们的物理终端和NVT进行相互转换。也就是说，不管客户进程终端是什么类型，操作 系统必须把它转换为NVT格式。同时，不管服务器进程的终端是什么类型，操作系统必须能够把NVT格式转换为终端所能够支持的格式。
物理终端与NVT的转换模型如图1-4所示。
图1-4 物理终端与NVT的转换模型
-
NVT ASCII
即7比特的ASCII字符集。发送时，每个7比特的字符的最高比特位加0后，以8比特的格式发送。网间网协议族使用的字符集是NVT ASCII。例如FTP、SMTP等。
-
IAC
Telnet通信的两个方向都是采用带内信令的方式，字节0xFF叫做IAC（Interpret As Command），即作为命令来解释。该字节后面的一个字节代表命令。
以下列出设备用到的命令及其含义：
-
SE：子选项结束
-
SB：子选项开始
-
WILL：选项协商
-
WONT：选项协商
-
DO：选项协商
-
DONT：选项协商
-
IAC：其后面的一个字节作为命令来解释
-
表1-1 RFC规定的Telnet命令集
|
名称 |
代码（十进制） |
描述 |
|---|---|---|
|
EOF |
236 |
文件结束符 |
|
SUSP |
237 |
挂起当前进程（作业控制） |
|
ABORT |
238 |
异常中止进程 |
|
EOR |
239 |
记录结束符 |
|
SE |
240 |
子选项结束 |
|
NOP |
241 |
无操作 |
|
DM |
242 |
数据标记 |
|
BRK |
243 |
中断 |
|
IP |
244 |
中断进程 |
|
AO |
245 |
异常中止输出 |
|
AYT |
246 |
对方是否还在运行 |
|
EC |
247 |
转义字符 |
|
EL |
248 |
删除行 |
|
GA |
249 |
继续进行 |
|
SB |
250 |
子选项开始 |
|
WILL |
251 |
选项协商 |
|
WONT |
252 |
选项协商 |
|
DO |
253 |
选项协商 |
|
DONT |
254 |
选项协商 |
|
IAC |
255 |
数据字节255 |
-
Telnet连接
一个Telnet连接就是一个用来传输带有Telnet控制信息数据的TCP连接。
-
Telnet的C/S模式
Telnet采用客户端/服务器模式。如图1-5显示了Telnet客户端和服务器连接的示意图。
图1-5 Telnet连接的示意图
通过该示意图，可知：
-
Telnet使用的传输协议为TCP。
-
Telnet连接的任何回显信息，最终都会输出到终端上。
-
服务器进程直接与“伪终端设备”交互。
-
客户端和服务器通过一条TCP连接来传输命令和数据。
-
客户端登录到服务器上。
-
Telnet工作原理
Telnet协议 可以工作在任何主机或者任何终端之间。因为，无论客户终端是什么类型，操作系统都会把它转换成NVT格式；同时，操作系统也会将NVT格式转换成服务器终 端所支持的类型。那么，可以屏蔽具体的客户端和终端类型，简单地认为Telnet双方都连接在NVT上。
Telnet采用对称性模型，因此理论上一个Telnet连接的每一端都必须有一个NVT。
Telnet连接的两端，通过“WILL、WONT、DO、DONT”请求来进行选项协商，从而确定Telnet服务的具体内容。这些选项包括回显、改变命令字符集、行方式等。
本节从以下几个方面介绍Telnet的工作原理：
-
Telnet中的请求
Telnet连接的任何一方都可以主动发起请求。请求的含义和用法如表1-2所示。
表1-2 Telnet中的请求的使用
发送方发出请求
含义
接受方应答
WILL
WONT
DO
DONT
WILL
发送方想激活选项
－
－
接收方同意
接收方不同意
WONT
发送方想禁止选项
－
－
－
接收方必须同意1)
DO
发送方想让接收方激活选项
接收方同意
接收方不同意
－
－
DONT
发送方想让接收方禁止选项
－
接收方必须同意1)
－
－
发起方发送“选项失效”请求（WONT和DONT）时，接收方必须同意；
发起方发送一些“选项有效”的请求，接收方可以接受或者拒绝这些请求：
-
如果接受请求，则选项立即生效；
-
如果拒绝请求，则选项不生效，而发送方仍然能保留NVT的特性。
-
-
选项协商
选项协商由3个字节组成，如下：
< IAC, WILL/DO/WONT/DONT之一,选项代码 >
下面举例说明Telnet中如何进行选项协商。
例如：服务器想跟客户端请求激活“远程流量控制”（选项标识是33），客户端表示同意激活该选项。两者交互的命令如下：
-
服务器：< IAC,WILL,33 >
-
客户端：< IAC,DO,33 >
-
-
子选项协商
在主机之间传递选项时，除了一个选项代码外，可能还需要其他更多的信息。例如，要求对方指定终端类型，则对方必须回应一个用ASCII字符串表示的终端类型。
子选项协商的格式如下：
< IAC,SB,选项代码,子选项内容信息,IAC,SE>
一次完整的子选项协商过程如下：
-
发送方发送一个带有选项代码的DO/WILL命令来请求激活该选项。
-
接收方发送一个带有选项代码的WILL/DO命令来同意激活该选项。
至此，双方都同意使用该选项。
其中一方通过SB命令后跟子选项代码，并且以SE结尾来开始子选项协商。
-
对方同样以SB命令后跟子选项代码和相关协商信息，并且以SE结尾来回应子选项协商。
-
另一方回应DO/WILL命令来同意该子选项。
如果没有其他子选项需要协商，则本次协商结束。
上述过程假设接收方同意发送方的请求。实际应用中，接收方根据需要，在任何时候都可以拒绝发送方的请求。
下面举一个终端类型协商的示例。
例如：客户端要激活本地的“终端类型”（选项标识是24）选项；服务器同意；服务器会发出询问客户端的终端类型的请求；客户端于是向服务器发送其终端类型为“DELL PC机”。两者交互的命令如下：
-
客户端：< IAC, WILL, 24 >
-
服务器：< IAC, DO, 24 >
-
服务器：< IAC, SB, 24, 1, IAC, SE >
-
客户端：< IAC, SB, 24, 0,‘D’,‘E’,‘L’,‘L’,‘P’,‘C’, IAC, SE >
-
只有DO类型的发送端可以发送请求。
-
只有WILL类型的发送端可以发送实际的类型信息。
终端类型信息不能以自动方式发送，而只能是以<请求－响应>的方式。
终端类型信息是NVT ASCII String字符串类型。该类型编码不区分大小写的差别。
-
-
操作方式
Telnet协议规定有4种操作方式。
-
半双工
-
一次一个字符
-
一次一行
-
行方式
-
设备中提供的Telnet服务
设备提供的Telnet服务包括：
-
Telnet Server
用户在PC上运行Telnet客户端程序登录到设备，对设备进行配置管理。
-
Telnet Client
用户在PC上通过终端仿真程序或Telnet客户端程序建立与设备的连接后，再执行telnet命令登录到其它设备，对其进行配置管理。如图1-6所示，SwitchA此时既作为Telnet Server，也同时提供Telnet Client服务。
图1-6 提供Telnet Client服务
1.2.4 SSH协议
概述
SSH是Secure Shell（安全外壳）的简称，标准协议端口号22。
Telnet缺少安全的认证方式，而且传输过程采用TCP进行明文传输，存在很大的安全隐患。单纯提供Telnet服务容易招致DoS（Deny of Service）、主机IP地址欺骗、路由欺骗等恶意攻击。
随着人们对网络安全的重视，传统的Telnet和FTP通过明文传送密码和数据的方式，已经慢慢不被人接受。SSH（Secure Shell）是一个网络安全协议，通过对网络数据的加密，解决了这个问题。它在一个不安全的网络环境中，提供了安全的远程登录和其他安全网络服务。
SSH通过TCP进行数据交互，它在TCP之上构建了一个安全的通道。另外SSH服务除了支持标准端口22外，还支持其他服务端口，以防止受到非法攻击。
SSH支持Password认证、DSA认证和RSA认证，对数据进行DES、3DES、AES等加密，有效防止了对密码的窃听，保护了数据的完整 性和可靠性，保证了数据的安全传输。特别是对于RSA和DSA认证的支持，对称加密和非对称加密的混合应用，密钥的安全交换，最终实现了安全的会话过程。
由于SSH数据加密传输，认证机制更加安全，SSH已经越来越被广泛使用，成为了当前最重要的网络协议之一。
SSH协议有两个版本：SSH1（SSH1.5）协议和SSH2（SSH 2.0）协议，两者是不同的协议，不兼容。SSH2.0在安全、功能和性能上均比SSH 1.5有优势。
设备支持STelnet的客户端和服务器端，以及SFTP的客户端和服务器端，均支持SSH1（SSH1.5）协议和SSH2（SSH 2.0）协议。
STelnet是Secure Telnet的简称，使得用户可以从远端安全登录到设备，提供交互式配置界面，所有交互数据均经过加密，实现安全的会话。
SFTP是Secure FTP的简称，使得用户可以从远端安全地登录到设备上进行文件管理，这样使远程系统升级等需要文件传送的地方，增加了数据传输的安全性。同时，由于提供了客户端功能，可以在本设备上安全FTP到远程设备，进行文件的安全传输。
SSH的基本概念
-
SFTP
SFTP（SSH File Transfer Protocol）。在一个传统不安全的网络环境中，服务器通过对客户端的认证及双向的数据加密，为网络文件传输提供了安全的服务。
-
SCP
SCP（Secure Copy）。在一个传统不安全的网络环境中，服务器通过对客户端的认证及双向的数据加密，为网络文件传输提供了安全的服务。
-
STelnet
一种安全的Telnet服务。在一个传统不安全的网络环境中，服务器通过对客户端的认证及双向的数据加密，为网络终端访问提供了安全的服务。
-
RSA认证
RSA（Revest-Shamir-Adleman Algorithm）身份认证是基于客户端私钥的一种认证方式。它是一种公开密钥加密体系，是一种非对称加密算法，其原理是基于大整数因子分解这一著名的 数学难题，主要用来传递对称加密算法所使用的密钥，通过这种方法可以有效地提高加密的效率并能简化对密钥的管理。
服务器必须检查用户是否是合法的SSH用户，检查公钥对于该用户是否合法，用户数字签名是否合法。若三者同时满足，则身份认证通过；若其中任何一项不能验证通过均告验证失败，拒绝该用户的登录请求。
-
DSA认证
DSA（Digital Signature Algorithm，数字签名算法）是由一种用于用户认证的非对称加密算法，由公钥和私钥两部分组成。
和RSA认证相同，服务器必须检查用户是否是合法的SSH用户，检查公钥对于该用户是否合法，用户数字签名是否合法。若三者同时满足，则身份认证通过；若其中任何一项不能验证通过均告验证失败，拒绝该用户的登录请求。
相比RSA认证，DSA认证采用数字签名算法进行加密，具有更广泛的应用性。
-
在SSH中，很多工具仅支持使用DSA进行服务器和客户端认证。
-
按照最新的SSH RFC定义，DSA认证比RSA更优先被选择使用。
-
-
Password认证
Password身份认证是基于“用户名＋口令”的一种认证方式。
在服务器端由AAA为每一个合法用户分配一个用于登录时进行身份验证的口令，即在服务器端存在“用户名＋口令”的一一对应的关系。当某个用户请求登录时，服务器需要对用户名以及其口令分别进行鉴别，其中任何一项不能验证通过均告验证失败，拒绝该用户的登录请求。
-
RSA-Password认证和DSA-Password认证
SSH服务器可以要求客户端进行身份认证的过程中同时进行Publickey身份认证和Password身份认证，只有当两者同时满足的情况下，才认为客户端身份认证通过。
-
ALL认证
服务器可以要求客户端进行身份认证的过程中进行公钥认证或密码认证，只要满足其中一个认证，就认为客户端身份认证通过。
设备中支持的SSH特性
-
支持基本的SSH协议
-
支持进入、外出使用不同加密算法。
-
支持进入、外出使用不同MAC算法。
-
支持3DES-cbc、DES、AES128（Advanced Encryption Standard）加密算法。
-
支持HMAC-sha1验证算法。
-
支持diffie-hellman-group1-sha1密钥交换算法。
-
支持SSH-RSA公钥格式。
-
支持SSH-DSA公钥格式。
-
支持密钥重交换Key Re-Exchange：重新进行密钥协商，协商的内容包括：使用的算法、算法使用的密钥。
-
支持Public key、Password认证方式。
-
-
SSH支持的客户端功能
SSH客户端功能允许用户与支持SSH Server的设备、UNIX主机等建立SSH连接。如图1-7、图1-8所示，可以建立SSH通道进行本地连接或广域网连接。
图1-7 在局域网内建立SSH通道
图1-8 通过广域网建立SSH通道
-
支持SFTP协议
SFTP协议基于SSH2。在一个传统不安全的网络环境中，服务器通过对客户端的认证及双向的数据加密，为网络文件传输提供了安全的服务。
设备支持的SFTP协议有如下功能：
-
支持SFTP客户端、服务器功能。
-
支持使能/去使能SFTP服务器功能（默认关闭）。
-
支持对应用户的SFTP访问默认目录设定。
-
-
支持SCP协议
SCP协议基于SSH2。在一个传统不安全的网络环境中，服务器通过对客户端的认证及双向的数据加密，为网络文件传输提供了安全的服务。
设备支持的SCP协议有如下功能：
-
支持SCP客户端、服务器功能。
-
支持使能/去使能SCP服务器功能（默认关闭）。
-
-
支持STelnet协议
设备支持的STelnet协议有如下功能：
-
支持STelnet客户端、STelnet服务器功能。
-
支持使能/去使能SSH Telnet服务器功能（默认关闭）。
-
-
SSH服务支持其他端口
SSH协议的标准监听端口号为22，攻击者不断访问标准端口，导致带宽和服务器性能的下降，其他正常用户无法访问，这是一种DoS（拒绝服务）攻击。
设定SSH服务端的监听端口号为其他端口，攻击者不知道SSH监听端口号的更改，有效防止攻击者对SSH服务标准端口访问消耗带宽和系统资源。正常用户通过对非标准端口的SSH服务的访问，降低DoS（拒绝服务）攻击可能性。
SSH服务支持其他端口，有如下应用：
-
STelnet/SFTP客户端支持指定其他端口号访问。
-
SSH服务器支持监听端口号的设定。
-
SSH协议的基本原理
SSH采用了传统Client/Server应用模型，其安全特性通过以下方式保证。
数据加密：通过Client/Server协商交换生成的Encryption Key，实现对数据报文的对称加密，确保数据在传输过程中的机密性。
数据完整性：通过Client/Server协商交换生成的Integrity Key唯一标识一条会话链路，所有会话交互报文被Integrity Key标识。一旦数据被第三方修改，接收方就能够检查出来，并丢弃报文，确保数据在传输过程中的完整性。
权限认证：通过提供多种认证方式，确保惟有认证通过的合法用户才能和Server进行会话，提高系统安全，同时保障合法用户的权益。
SSH处理流程
SSH连接在整个通讯过程中，经过如图1-9所示六个阶段，协商实现SSH认证安全连接，下面介绍一下SSH协商阶段的整个过程。
图1-9 SSH连接协商过程
-
版本协商阶段
SSH Client向Server发起TCP连接请求。TCP连接建立后，SSH Server和Client之间协商版本号。协商出匹配的版本协议，对不同版本协议走不同的状态机流程。如果版本匹配，进入密钥协商阶段；否则SSH Server断开TCP连接。
-
算法协商
当进入算法协商过程后，发送方向接收方发送算法协商消息包，发送方同时将随机Cookie、密钥交换的算法、主机密钥算法、支持的MAC（Message Authentication Code）认证方法以及支持的语言等作为消息的参数发送给接受方。
接收方等待接收到发送方的算法协商消息后，将发送方的算法列表集合与本地算法列表集合相比较。若密钥交换算法、公钥加密算法和MAC算法当中有一项没有找到，则断开与发送方的连接，算法协商失败。
-
密钥交换阶段
当算法协商通过后，进入密钥交换阶段。双方开始计算会话ID。客户端随机生成一个32字节的会话密钥（session key），用该密钥的前16字节异或（XOR）会话ID的16字节，后16字节不变，所得结果按MSB排列成一个MP型整数。用主机公钥和服务器公钥中模数较小的公钥进行加密，把结果按MSB first顺序排列成一个MP型整数，用模数较大的公钥进行加密，并把所得结果和客户端选择的加密算法、服务器传来的8字节Cookie、自身的协议标志一起发给服务器端。
会话过程中，大数据量传输必须使用处理速度较快的对称密钥算法。对称加解密需要共享密钥，密钥交换流程目的是在不安全的通道中安全传送会话密钥。
服务器处于等待状态，当收到客户端发送的密钥生成消息包后，服务器回送一个密钥生成消息给客户端，表示密钥交换完成，采用新的密钥进行通讯。如果失败，则返回密钥交换失败消息，并断开连接。
-
认证阶段
在计算出会话密钥后，SSH Server对Client进行用户身份验证。SSH Client向Server发送用户身份信息。如果SSH Server上配置该用户无需验证，则直接进入请求会话阶段；如果在SSH Server上配置对该用户进行验证，Client将采用配置的验证方法向Server提出验证请求，直到验证通过或连接超时断开。
SSH Server提供六种验证方法：RSA、Password、RSA-Password、DSA、DSA-Password和ALL。
-
在RSA认证方式下，用户客户端程序生成一个RSA密钥对，并将公钥部分发送给服务器端。用户发起认证请求时，客户端程序随机生成一段有私 钥加密的密文并发送给服务器端，服务器端利用公钥对其进行解密，解密成功就认为用户是可信的，随机对用户授予相应得访问权限。否则，中断连接。
-
在DSA认证方式下，用户客户端程序生成一个DSA密钥对，并将公钥部分发送给服务器端。用户发起认证请求时，客户端程序随机生成一段有私 钥加密的密文并发送给服务器端，服务器端利用公钥对其进行解密，解密成功就认为用户是可信的，随机对用户授予相应得访问权限。否则，中断连接。
-
Password认证依靠AAA实现，与Telent和FTP类似，支持本地数据库和远程RADIUS服务器验证，SSH Server对来自Client的用户名/口令和预先配置的用户名/口令进行比较，如果完全匹配则验证通过。
-
-
会话请求阶段
认证完成后，客户端向服务器提交会话请求。会话请求包含shell和命令。服务器则进行等待，处理客户端的请求。在这个阶段，无论什么请求只要成功处理了，服务器都向客户端回应认证成功消息；否则回应认证失败消息，这表示认证失败。
认证失败的原因如下：
-
服务器处理请求失败
-
服务器不能识别请求
-
-
交互会话阶段
会话申请成功后，连接进入交互会话模式。在这个模式下，数据在两个方向上双向传送。
- 客户端将要执行的命令加密后打包传给服务器。
- 服务器接收到报文，解密后执行该命令，并将执行的结果加密、打包、发还给客户端。
- 客户端将接收到的结果解密后显示到终端上。
1.2.5 SSL协议
概述
安全套接层SSL（Secure Sockets Layer）协议是在Internet基础上提供的一种保证私密性的安全协议。它能使客户端与服务器之间的通信不被攻击者窃听，并且始终对服务器进行认证，还可选择对客户端进行认证。
SSL协议与应用层协议相互独立，应用层协议（例如：HTTP，FTP）能透明的建立于SSL协议之上。SSL协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。
SSL具有如下优点：
- 提供较高的安全性保证。SSL利用数据加密、身份验证和消息完整性验证机制，保证网络上数据传输的安全性。
- 支持各种应用层协议。虽然SSL设计的初衷是为了解决万维网安全性问题，但是由于SSL位于应用层和传输层之间，它可以为任何基于TCP等可靠连接的应用层协议提供安全性保证。
- 部署简单。目前SSL已经成为网络中用来鉴别网站和网页浏览者身份，在浏览器使用者及Web服务器之间进行加密通信的全球化标准。
协议安全机制
-
连接的私密性
SSL利用对称加密算法对传输数据进行加密，并利用密钥交换算法—RSA（Rivest Shamir and Adleman，非对称密钥算法的一种）加密传输对称密钥算法中使用的密钥。
-
身份验证机制
基于证书利用数字签名方法对服务器和客户端进行身份验证，其中客户端的身份验证是可选的。SSL服务器和客户端通过PKI（Public Key Infrastructure，公钥基础设施）提供的机制从CA（Certificate Authority，认证机构）获取证书。
-
内容的可靠性
消息传输过程中使用基于密钥的MAC（Message Authentication Code，消息验证码）来检验消息的完整性。
MAC算法是将密钥和任意长度的数据转换为固定长度数据的一种算法。
- 发送端在密钥参与下，利用MAC算法计算出消息的MAC值，并将其加在消息之后发送给接收端。
- 接收端利用同样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。
如果二者相同，则报文没有改变。否则，报文在传输过程中被修改，接收端将丢弃该报文。
协议工作过程
-
SSL协议结构
如图1-10所 示，SSL位于应用层和传输层之间，它可以为任何基于TCP等可靠连接的应用层协议提供安全性保证。SSL协议分为两层：底层是SSL记录协议（SSL record protocol）；上层是SSL握手协议（SSL handshake protocol）、SSL密码变化协议（SSL change cipher spec protocol）和SSL警告协议（SSL alert protocol）。
图1-10 SSL协议栈
- SSL记录协议：主要负责对上层的数据进行分块、计算并添加MAC、加密，最后把记录块传输给对方。
- SSL握手协议：是SSL协议非常重要的组成部分，用来协商通信过程中使用的加密套件（对称加密算法、密钥交换算法和MAC算法等）、在服务器和 客户端之间安全地交换密钥，实现服务器和客户端的身份验证。客户端和服务器通过握手协议建立一个会话，会话包含一组参数，主要有会话ID、对方的证书、加 密套件（包括密钥交换算法、数据加密算法和MAC算法）及主密钥。
- SSL密码变化协议：客户端和服务器端通过密码变化协议通知接收方，随后的报文都将使用新协商的加密套件和密钥进行保护和传输。
- SSL警告协议：用来允许一方向另一方报告告警信息。消息中包含告警的严重级别和描述。
-
SSL握手过程
SSL通过握手过程在客户端和服务器之间协商会话参数，并建立会话。会话包含的主要参数有会话ID、对方的证书、加密套件（密钥交换算法、数据加密算法和MAC算法等）以及主密钥。通过SSL会话传输的数据，都将采用该会话的主密钥和加密套件进行加密、计算MAC等处理。
不同情况下，SSL握手过程存在差异。下面将分别描述以下三种情况下的握手过程：
-
只验证服务器的SSL握手过程
图1-11 只验证服务器的SSL握手过程示意图
如图1-11所示，只需要验证SSL服务器身份，不需要验证SSL客户端身份时，SSL的握手过程如下：
- SSL客户端通过Client Hello消息将它支持的SSL版本、加密算法、密钥交换算法、MAC算法等信息发送给SSL服务器。
- SSL服务器确定本次通信采用的SSL版本和加密套件，并通过Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配会话ID，并通过 Server Hello消息发送给SSL客户端。
- SSL服务器将携带自己公钥信息的数字证书通过Certificate消息发送给SSL客户端。
- SSL服务器发送Server Hello Done消息，通知SSL客户端版本和加密套件协商结束，开始进行密钥交换。
- SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的密钥，并通过Client Key Exchange消息发送给SSL服务器。
- SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
- SSL客户端计算已交互的握手消息（除Change Cipher Spec 消息外所有已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给 SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC 值验证成功，则证明密钥和加密套件协商成功。
- 同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
- SSL服务器计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC 值、加密等），并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息 的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证 成功。因为只有拥有私钥的SSL服务器才能从Client Key Exchange消息中解密得到密钥，从而间接地实现了SSL客户端对SSL服务器的身份验证。
- Change Cipher Spec消息属于SSL密码变化协议，其他握手过程交互的消息均属于SSL握手协议，统称为SSL握手消息。
- 计算Hash值，指的是利用Hash算法（MD5或SHA）将任意长度的数据转换为固定长度的数据。
-
验证服务器和客户端的SSL握手过程
图1-12 验证服务器和客户端的SSL握手过程示意图
SSL客户端的身份验证是可选的，由SSL服务器决定是否验证SSL客户端的身份。如图1-12中蓝色部分标识的内容所示，如果SSL服务器验证SSL客户端身份，则SSL服务器和SSL客户端除了只验证服务器的SSL握手过程中的消息协商密钥和加密套件外，还需要进行以下操作：
- SSL服务器发送CertificateRequest消息，请求SSL客户端将其证书发送给SSL服务器。
- SSL客户端通过Certificate消息将携带自己公钥的证书发送给SSL服务器。SSL服务器验证该证书的合法性。
- SSL客户端计算已交互的握手消息、主密钥的Hash值，利用自己的私钥对其进行加密，并通过Certificate Verify消息发送给SSL服务器。
- SSL服务器计算已交互的握手消息、主密钥的Hash值，利用SSL客户端证书中的公钥解密Certificate Verify消息，并将解密结果与计算出的Hash值比较。如果二者相同，则SSL客户端身份验证成功。
-
恢复原有会话的SSL握手过程
图1-13 恢复原有会话的SSL握手过程示意图
协商会话参数、建立会话的过程中，需要使用非对称密钥算法来加密密钥、验证通信对端的身份，计算量较大，占用了大量的系统资源。为了简化SSL握手过程，SSL允许重用已经协商过的会话，如图1-13所示，具体过程如下：
- SSL客户端发送Client Hello消息，消息中的会话ID设置为计划重用的会话的ID。
- SSL服务器如果允许重用该会话，则通过在Server Hello消息中设置相同的会话ID来应答。这样，SSL客户端和SSL服务器就可以利用原有会话的密钥和加密套件，不必重新协商。
- SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用原有会话的密钥和加密套件进行加密和MAC计算。
- SSL客户端计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSL服务器，以便SSL服务器判断密钥和加密套件是否正确。
- 同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用原有会话的密钥和加密套件进行加密和MAC计算。
- SSL服务器计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSL客户端，以便SSL客户端判断密钥和加密套件是否正确。
-
1.2.6 两阶段生效模式
基本原理
两阶段生效模式，就是通过两个阶段的操作过程配置才能生效。如图1-14所示，两阶段生效模式分两个步骤进行：
图1-14 两阶段生效模式的步骤示意图
-
第一阶段用户输入配置命令，系统在候选数据集中进行数据类型、用户级别、操作对象检查，同时进行重复配置检查。对于语法或者语义错误的配置语句，系统将在终端上显示提示信息，提醒用户配置错误及错误原因。
-
第二阶段用户提交配置，系统进入配置的提交阶段。系统提交候选数据集中的配置到运行数据集。
-
如果业务生效成功，系统将该配置合并到运行数据集。
-
如果业务生效失败，系统将提示用户配置错误的信息。用户可以重新输入配置命令修改配置，然后重新提交。
-
两阶段生效模式中的几个概念如下：
-
运行数据集
系统当前运行的配置的集合。
-
候选数据集
在两阶段生效模式的功能中，系统为每一位用户在设备的内存中创建运行数据集的镜像，即候选数据集。用户可以在其中进行配置编辑，确认编辑完成后，将配置提交至运行数据集。
合法性检查
用户在进入系统视图后，系统为每个用户分配一个候选数据集。用户在分配的候选数据集中进行配置，同时系统基于当前用户的配置，进行合法性检查。
两阶段生效模式可以检查配置是否合法，并提示用户错误信息。合法性的检查包括如下几项：
-
重复的配置
系统会检测候选数据集中的配置是否与运行数据集中的一致。
-
如果一致，则系统无需提交，并且提示有哪些重复的配置命令。
-
如果不一致，则系统提交用户的配置至运行数据集。
-
-
数据类型不合法
-
用户级别无权执行某些命令
-
操作的对象不存在
多用户并行执行
如图1-15所示，多个用户可以对同一台设备进行并行配置。
图1-15 多用户并行执行两阶段生效模式的示意图
使用价值
两阶段生效模式具有以下使用价值：
-
用户要求对业务的配置能够整体生效。
-
用户可以预览候选数据集里面的配置。
-
用户在预览配置后发现业务配置产生错误或配置不符合用户预期时，能够立即清除未生效的配置。
-
用户要求把配置过程对现有业务的影响降到最低。
1.2.7 配置回退
产生原因
用户提交配置后，一般会去查看运行配置和配置对网络的影响，或者配置错误、配置产生故障、配置对网络产生了超出预期的结果时，需要恢复原来的配置。
通常情况下，
- 用户如果没有办法查看最近几次进行的配置，只能通过查看目前的配置凭印象推测；
- 当用户发现配置错误或者发现配置对网络产生了超出预期的结果，只能逐条手动进行删除或者修改，而不能对配置进行批量恢复。
为了解决上述问题，可以通过配置回退功能，通过查看该回退点的配置与当前配置的差异选择所需的配置回退点，然后使系统的配置在不重启系统且不中断业务的条件下回退到用户认为合适的配置点。
如图1-16所示，用户进行了N次配置，每次配置用户可配置多条命令，进行一次配置提交，此时系统都会自动生成一个对应的配置回退点。
配置回退点N是用户最近一次配置对应的配置回退点。用户执行配置回退操作，使系统回退至配置回退点X的配置历史状态，同时系统生成配置回退点N+1。配置回退点N+1对应的系统配置与配置回退点X对应的系统配置一致，从而达到回退配置的目的。
图1-16 配置回退示意图
相关概念
-
配置回退点：记录用户的历史配置，用于回退系统配置到历史状态。用户每次配置提交（一阶段或者二阶段），设备自动保存一个配置回退点，配置回退点内容为本次用户提交的配置。用户可以通过命令查看当前系统中的回退点信息。
- 配置回退：用户多次配置提交后，发现前面提交的配置有错误或者发现配置对业务产生了超出预期的结果，用户可以通过配置回退功能回退到指定的配置回 退点。例如：用户做了四次配置提交，形成a，b，c，d四个连续回退点，此时用户发现b的配置有错误，用户想回退到提交b之前的运行配置。用户执行配置回 退，回退至a。
基本功能
配置回退特性包括配置回退点生成、配置回退点查看、配置回退点内容查看、回退配置回退点和删除配置回退点这几个基本功能：
- 配置回退点的生成：用户每次配置（一阶段）、配置提交（二阶段）成功时会自动保存一个配置回退点，配置回退点中记录了用户操作的配置，系统最大可以生成50个回退点。而且，在配置提交时，用户可以为即将生成的配置回退点设置注释信息。
- 配置回退点信息的查看：用户可查看系统中已经生成的配置回退点信息，配置回退点信息包括配置回退点的LABLE（唯一标识一个配置回退点的标 号）、触发生成配置回退点的用户名称、配置时的终端类型（例如console、vty）、配置使用的配置工具端类型（CLI、SNMP、NETCONF 等）、配置回退点时间戳以及注释信息。
- 配置回退点内容的查看：用户可以查看某配置回退点中所进行的配置，而且用户还可以查看当前配置和若干次配置前的配置差异，由此可以分析如果执行回退，可能变化的配置有哪些，从而确定执行是否执行配置回退，以及如果配置回退会对系统产生造成哪些影响。
- 配置回退：用户可以指定从当前配置回退到哪个回退点，从指定的回退点到当前配置这个过程中用户的配置变更都会被回退。例如，创建的配置会被删除、删除的配置会被重新创建、修改的配置会被改回原值。
- 删除较早的配置回退点：用户删除系统中最早生成的配置回退点，可清除系统中无用的信息，节省系统资源（比如磁盘空间）。
实现流程
配置回退的实现由以下几个步骤组成：
- 用户下发配置回退请求，并指明配置回退点。
- 系统检查回退点是否合法，经过权限验证后执行配置回退事务。
- 系统读取当前配置与历史配置点的配置差异，并以逆序的方式将其逆配置操作保存。
- 系统执行所有逆操作过程，替换当前运行配置，最后使得业务生效。
使用价值
配置回退功能在配置安全性与系统可维护性方面给用户带来了更大的方便，具体如下：
-
命令行用户由于误操作，删除了系统中的业务配置，比如undo mpls，会导致所有与mpls相关的配置被删除。此时用户可以通过配置回退功能，快速恢复相应的数据，使系统恢复误操作前的历史状态，减小误操作对系统的影响。
-
网管用户同时给多个网元进行配置，有的网元配置成功，有的网元配置失败。网管用户可以通过回退功能，回退所有网元到配置前的历史状态，从而保障多网元配置的一致性。
-
用户配置每个特性（一次配置提交）时可以保存一个配置回退点。用户测试每个特性前，需要清除其它特性对此特性的影响。用户测试新特性前，通过回退功能，可以很方便地使系统回退到该特性配置前的状态。
1.3 应用
1.3.1 TFTP
使用TFTP上传/下载文件：
当用户需要从服务器上传/下载文件且不需要复杂的交互环境时，可以使用TFTP协议。设备目前只能作为TFTP客户端使用。
组网图如图1-17所示。
图1-17 利用TFTP功能下载或上传文件
1.3.2 FTP
-
设备作为FTP客户端
从充当FTP客户端的设备上登录到FTP服务器，从服务器端下载系统文件到客户端的存储设备中。
如图1-18中，IP地址为172.16.105.111的设备作为FTP客户端。则可以在作为FTP客户端的设备上以FTP的方式登录到FTP服务器上去。
图1-18 设备作为FTP客户端
-
设备作为FTP服务器
设备作为FTP服务器，从超级终端登录到客户端设备上，再从FTP服务器下载文件。如图1-19中，IP地址为172.16.104.110的设备作为FTP服务器。
图1-19 设备作为FTP服务器
1.3.3 Telnet
-
设备作为Telnet服务器
用户在PC上运行Telnet客户端程序登录到设备，对设备进行配置管理。
-
设备作为Telnet客户端
用户在PC上通过终端仿真程序或Telnet客户端程序建立与设备的连接后，再执行telnet命令登录到其它设备，对其进行配置管理。如图1-20所示，SwitchA此时既作为Telnet Client，也同时提供Telnet Server服务。
图1-20 提供Telnet Client服务
-
重定向终端服务
当用户需要管理远程设备，且远程设备只能通过串口传输数据时，可以通过设备的重定向服务来实现。远程设备可以是路由器、交换机、电力或者金融系统终端等其他支持串口配置的设备。
用户在PC上运行Telnet客户端程序以特定的端口号登录到设备，再与设备异步口连接的串口设备建立连接，如图1-21所示。
图1-21 重定向连接其他设备示意图（1）
远程设备还可以是智能电表，智能水表或者银行自助系统等终端设备。
如图1-22所示，启用重定向服务后，设备监听相应的TCP端口，从串口接收由终端设备发送的数据流。接收到数据流后，设备对数据进行封装，使之成为可以在以太网中传播的数据帧，从而实现终端设备的远程数据传输与管理。
图1-22 重定向连接其他设备示意图（2）
只有提供异步口的设备才支持Telnet重定向服务。
1.3.4 SSH
-
支持STelnet的客户端和服务器端
STelnet客户端基于SSH2协议，服务器端基于SSHv1.x和SSHv2协议。客户端和服务器之间经过协商，建立安全连接，客户端可以像操作Telnet一样登录服务器，之后进行配置操作，如图1-23所示。
图1-23 SSH支持Stelnet协议
-
设备支持STelnet客户端、STelnet服务器功能：为了方便用户的使用，设备不仅提供STelnet服务器功能，同时也可以做为STelnet客户端访问其他STelnet服务器。
-
支持使能/去使能STelnet服务器功能（默认关闭）：在不需要STelnet服务器情况下可以将其去使能，该功能在全局模式下配置。
-
-
支持SFTP的客户端和服务器端
攻击者没有正确的私钥和密码，无法通过服务器的认证，并且攻击者无法获得其他用户和服务器之间的会话密钥，因此后续服务器和指定客户端的通讯报文只有指定客户端和服务器才能解密。即使攻击者窃听到通讯报文，也不能解密，实现了网络数据传输的安全性。
SFTP是基于SSH2的安全文件传输协议。SSH2支持两种认证方式：密码认证和RSA认证。合法用户通过客户端登录时，输入正确的用户名以及对 应的密码和私钥，通过服务器的验证。此时用户可以像使用FTP一样使用，实现对网络文件的远程传输管理，而系统会对用户的数据采用协商出来的会话密钥对数 据加密。
-
支持SFTP客户端、SFTP服务器功能：为了方便用户的使用，设备不仅提供SFTP服务器功能，同时也可以做为SFTP客户端访问其他SFTP服务器。
-
支持使能/去使能SFTP服务器功能（默认关闭）：在不需要SFTP服务器情况下可以将其去使能，该功能在全局模式下配置。
-
支持对应用户的SFTP访问默认目录设定：对于不同的用户，服务器允许访问的文件目录不同。用户只能访问SFTP服务设定目录，因此通过对应用户的SFTP访问默认目录设定实现不同用户文件隔离。
图1-24 SSH支持SFTP协议
-
-
支持SCP的客户端和服务器端
攻击者没有正确的私钥和密码，无法通过服务器的认证。并且攻击者无法获得其他用户和服务器之间的会话密钥，因此后续服务器和指定客户端的通讯报文只有指定客户端和服务器才能解密。即使攻击者窃听到通讯报文，也不能解密，实现了网络数据传输的安全性。
SCP是基于SSH2的安全文件传输协议。SSH2支持两种认证方式：密码认证和RSA认证。合法用户通过客户端登录时，输入正确的用户名以及对应 的密码和私钥，通过服务器的验证。此时用户可以像使用FTP一样使用，实现对网络文件的远程传输管理，而系统会对用户的数据采用协商出来的会话密钥对数据 加密。
-
支持SCP客户端、SCP服务器功能：为了方便用户的使用，设备不仅提供SCP服务器功能，同时也可以做为SCP客户端访问其他SCP服务器。
-
支持使能/去使能SCP服务器功能（默认关闭）：在不需要SCP服务器情况下可以将其去使能，该功能在全局模式下配置。
图1-25 SSH支持SCP协议
-
-
私网访问
设备支持STelnet客户端、SFTP客户端和SCP客户端，因此可以建立基于VPN的Socket连接，在公网设备实现如下访问：
-
STelnet客户端访问私网SSH服务器
-
SFTP客户端访问私网SSH服务器
-
SCP客户端访问私网SSH服务器
图1-26 SSH支持私网访问
-
-
SSH服务器支持其他端口访问
SSH协议的标准监听端口号为22，如果攻击者不断访问标准端口，将致带宽和服务器性能的下降，导致其他正常用户无法访问。
通过设定SSH服务器端的监听端口号为其他端口号，攻击者不知道SSH监听端口号的更改，仍然发送标准端口号22的Socket连接，SSH服务器检测发现请求连接端口号不是监听的端口号，就不建立Socket连接。
只有合法的用户采用SSH服务器设定的非标准监听端口才能建立Socket连接，进行SSH协议的版本号协商、算法协商及会话密钥生成、认证、会话请求和会话阶段等过程。
SSH服务可以应用在网络中的中间交换设备、边缘设备上，可以实现用户对设备的安全访问和管理。
图1-27 SSH服务器支持其他端口访问
-
支持RADIUS
SSH的如果使用密码认证，与FTP、Telnet一样，也是调用AAA提供的接口。在AAA中配置用户认证为RADIUS方式，当SSH认证启动 时，SSH服务器将SSH客户端的认证信息（用户名、密码）发送给RADIUS服务器（兼容TACACS服务器）进行认证；RADIUS服务器认证该用 户，将认证结果（成功、失败，如果成功还包含用户等级）返回给SSH服务器。SSH服务器根据认证结果决定是否允许SSH客户端建立连接。
图1-28 SSH支持RADIUS
-
支持ACL应用
ACL是地址访问控制列表。通过ACL对SSH类型的用户界面限制呼入呼出权限，防止一些非法地址的用户进行TCP连接，避免其进入SSH协商，借此提高SSH服务器安全性。
图1-29 SSH支持ACL应用
-
支持SNETCONF
NETCONF Agent是运行于SSH Server之上的一种应用。使用SSH建立的安全传输通道。NETCON被用来访问配置、声明信息和修改配置信息，因此访问此协议的能力应当被限制为用 户和系统。在SSH上运行NETCONF，Client需要先使用SSH传输协议来建立SSH传输连接。Client和Server为了消息的完整性而交 换密钥并对密钥加密。一旦用户认证成功，Client就调用“SSH-连接”服务，即我们所知的SSH连接协议。在SSH连接服务建立后，Client为 SSH会话打开一个会话类型的通道。一旦SSH会话建立，用户（或者应用）调用SNETCONF作为SSH的一个子系统，这个是SSHv2的一个特性。 SSH Sever确保SNETCONF子系统传输数据的可靠性和数据顺序。
图1-30 在SSH Server上应用NETCONF组网图
1.3.5 SSL
SSL应用于FTP和HTTP，即FTPS和HTTPS。FTPS将FTP和SSL结合，HTTPS将HTTP和SSL结合，通过SSL对客户端身份和服务器进行验证，对传输的数据进行加密，从而实现了对设备的安全管理。
-
从终端登录作为FTPS服务器的设备
如图1-31所示，在作为FTP服务器的设备上部署SSL策略，并使能安全FTP服务器功能后，用户在终端通过支持SSL的FTP客户端软件登录安全FTP服务器，在终端与服务器之间实现文件的安全管理操作。
图1-31 通过终端登录FTPS服务器组网图
-
设备作为客户端通过FTPS登录FTPS服务器
如图1-32所示:
- 在作为FTP客户端的设备上部署SSL策略并加载信任证书机构文件，检查证书持有者身份的合法性，并签发证书，以防证书被伪造或篡改，以及对证书和密钥进行管理。
- 在作为FTP服务器的设备上部署SSL策略，并使能安全FTP服务器功能。
图1-32 通过FTPS客户端登录FTPS服务器组网图
在FTP客户端和FTP服务器之间路由可达的情况下，从FTP客户端登录到安全FTP服务器上实现远程管理文件。
-
从终端通过HTTPS登录设备
如图1-33所示，在作为HTTP服务器的设备上部署SSL策略，并使能安全HTTP服务器功能后，用户可以在终端通过浏览器登录HTTPS服务器，利用Web页面安全管理远程设备。 图1-33 通过浏览器登录HTTPS服务器
1.4 参考标准和协议
本特性的参考资料清单如下：
|
文档 |
描述 |
备注 |
|---|---|---|
|
RFC775 |
Directory oriented FTP commands |
– |
|
RFC959 |
File Transfer Protocol |
– |
|
RFC1635 |
How to Use Anonymous FTP |
– |
|
RFC1350 |
The TFTP Protocol Revision 2) |
– |
|
RFC698 |
Telnet Extended ASCII Option |
– |
|
RFC775 |
Directory oriented FTP commands |
– |
|
RFC854 |
Telnet Protocol Specification |
– |
|
RFC855 |
Telnet Option Specification |
– |
|
RFC930 |
Telnet Terminal Type Option |
– |
|
RFC1091 |
Telnet Terminal-Type Option |
– |
|
RFC2119 |
Key words for use in RFCs to Indicate Requirement Levels |
– |
|
RFC4250 |
The Secure Shell SSH) Protocol Assigned Numbers |
– |
|
RFC4251 |
The Secure Shell SSH) Protocol Architecture |
– |
|
RFC4252 |
The Secure Shell SSH) Authentication Protocol |
– |
|
RFC4253 |
The Secure Shell SSH) Transport Layer Protocol |
不支持压缩、不支持ssh-dss公钥格式 |
|
RFC4254 |
The Secure Shell SSH) Connection Protocol |
以下报文或功能不支持：X11转发功能Env通道请求报文、xon-xoff通道请求报文、Signal通道请求报文、exit-status通道请求报文、exit-signal通道请求报文、端口转发功能 |
|
RFC4344 |
The Secure Shell SSH) Transport Layer Encryption Modes |
– |
|
RFC4345 |
Improved Arcfour Modes for the Secure Shell SSH) Transport Layer |
– |
|
draft-ietf-secsh-publickey-subsystem-01 |
Authentication Mechanism that Is Based on Public Keys |
– |
转载于:https://www.cnblogs.com/swordxia/p/3937553.html