網絡傳輸基本協議

介紹

定義

在配置管理中，終端服務特性提供了設備配置的管理接入接口和交互界面，為用戶提供操作場所。

主要包括：

• 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連接主動模式建立過程

1. 服務器打開端口21啟動監聽，等待連接。
2. 客戶端發起控制連接的建立請求，服務器響應連接，控制連接建立。
3. 客戶端通過控制連接發送PORT命令，將客戶端數據連接的臨時端口號告訴服務器。
4. 服務器的20號端口與客戶端建立起數據連接。

被動模式FTP連接建立

FTP連接被動模式建立過程如圖1-3所示。

圖1-3  FTP連接被動模式建立過程

1. 服務器打開端口21啟動監聽，等待連接。
2. 客戶端發起控制連接的建立請求，服務器響應連接，控制連接建立。
3. 客戶端通過控制連接發送命令字PASV，告知服務器處於被動模式。
4. 服務器回應，將服務器數據連接的臨時端口號告訴客戶端。
5. 客戶端與服務器的臨時端口建立起數據連接。

說明：

臨時端口為隨機產生。

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連接協商過程

1. 版本協商階段

   SSH Client向Server發起TCP連接請求。TCP連接建立后，SSH Server和Client之間協商版本號。協商出匹配的版本協議，對不同版本協議走不同的狀態機流程。如果版本匹配，進入密鑰協商階段；否則SSH Server斷開TCP連接。

2. 算法協商

   當進入算法協商過程后，發送方向接收方發送算法協商消息包，發送方同時將隨機Cookie、密鑰交換的算法、主機密鑰算法、支持的MAC（Message Authentication Code）認證方法以及支持的語言等作為消息的參數發送給接受方。

   接收方等待接收到發送方的算法協商消息后，將發送方的算法列表集合與本地算法列表集合相比較。若密鑰交換算法、公鑰加密算法和MAC算法當中有一項沒有找到，則斷開與發送方的連接，算法協商失敗。

3. 密鑰交換階段

   當算法協商通過后，進入密鑰交換階段。雙方開始計算會話ID。客戶端隨機生成一個32字節的會話密鑰（session key），用該密鑰的前16字節異或（XOR）會話ID的16字節，后16字節不變，所得結果按MSB排列成一個MP型整數。用主機公鑰和服務器公鑰中模數較小的公鑰進行加密，把結果按MSB first順序排列成一個MP型整數，用模數較大的公鑰進行加密，並把所得結果和客戶端選擇的加密算法、服務器傳來的8字節Cookie、自身的協議標志一起發給服務器端。

   會話過程中，大數據量傳輸必須使用處理速度較快的對稱密鑰算法。對稱加解密需要共享密鑰，密鑰交換流程目的是在不安全的通道中安全傳送會話密鑰。

   服務器處於等待狀態，當收到客戶端發送的密鑰生成消息包后，服務器回送一個密鑰生成消息給客戶端，表示密鑰交換完成，采用新的密鑰進行通訊。如果失敗，則返回密鑰交換失敗消息，並斷開連接。

4. 認證階段

   在計算出會話密鑰后，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的用戶名/口令和預先配置的用戶名/口令進行比較，如果完全匹配則驗證通過。

5. 會話請求階段

   認證完成后，客戶端向服務器提交會話請求。會話請求包含shell和命令。服務器則進行等待，處理客戶端的請求。在這個階段，無論什么請求只要成功處理了，服務器都向客戶端回應認證成功消息；否則回應認證失敗消息，這表示認證失敗。

   認證失敗的原因如下：

   • 服務器處理請求失敗

   • 服務器不能識別請求

6. 交互會話階段

   會話申請成功后，連接進入交互會話模式。在這個模式下，數據在兩個方向上雙向傳送。

   1. 客戶端將要執行的命令加密后打包傳給服務器。
   2. 服務器接收到報文，解密后執行該命令，並將執行的結果加密、打包、發還給客戶端。
   3. 客戶端將接收到的結果解密后顯示到終端上。

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的握手過程如下：

    1. SSL客戶端通過Client Hello消息將它支持的SSL版本、加密算法、密鑰交換算法、MAC算法等信息發送給SSL服務器。
    2. SSL服務器確定本次通信采用的SSL版本和加密套件，並通過Server Hello消息通知給SSL客戶端。如果SSL服務器允許SSL客戶端在以后的通信中重用本次會話，則SSL服務器會為本次會話分配會話ID，並通過 Server Hello消息發送給SSL客戶端。
    3. SSL服務器將攜帶自己公鑰信息的數字證書通過Certificate消息發送給SSL客戶端。
    4. SSL服務器發送Server Hello Done消息，通知SSL客戶端版本和加密套件協商結束，開始進行密鑰交換。
    5. SSL客戶端驗證SSL服務器的證書合法后，利用證書中的公鑰加密SSL客戶端隨機生成的密鑰，並通過Client Key Exchange消息發送給SSL服務器。
    6. SSL客戶端發送Change Cipher Spec消息，通知SSL服務器后續報文將采用協商好的密鑰和加密套件進行加密和MAC計算。
    7. SSL客戶端計算已交互的握手消息（除Change Cipher Spec 消息外所有已交互的消息）的Hash值，利用協商好的密鑰和加密套件處理Hash值（計算並添加MAC值、加密等），並通過Finished消息發送給 SSL服務器。SSL服務器利用同樣的方法計算已交互的握手消息的Hash值，並與Finished消息的解密結果比較，如果二者相同，且MAC 值驗證成功，則證明密鑰和加密套件協商成功。
    8. 同樣地，SSL服務器發送Change Cipher Spec消息，通知SSL客戶端后續報文將采用協商好的密鑰和加密套件進行加密和MAC計算。
    9. 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握手過程中的消息協商密鑰和加密套件外，還需要進行以下操作：

    1. SSL服務器發送CertificateRequest消息，請求SSL客戶端將其證書發送給SSL服務器。
    2. SSL客戶端通過Certificate消息將攜帶自己公鑰的證書發送給SSL服務器。SSL服務器驗證該證書的合法性。
    3. SSL客戶端計算已交互的握手消息、主密鑰的Hash值，利用自己的私鑰對其進行加密，並通過Certificate Verify消息發送給SSL服務器。
    4. SSL服務器計算已交互的握手消息、主密鑰的Hash值，利用SSL客戶端證書中的公鑰解密Certificate Verify消息，並將解密結果與計算出的Hash值比較。如果二者相同，則SSL客戶端身份驗證成功。

  • 恢復原有會話的SSL握手過程

    圖1-13  恢復原有會話的SSL握手過程示意圖
    
    協商會話參數、建立會話的過程中，需要使用非對稱密鑰算法來加密密鑰、驗證通信對端的身份，計算量較大，占用了大量的系統資源。為了簡化SSL握手過程，SSL允許重用已經協商過的會話，如 圖1-13所示，具體過程如下：

    1. SSL客戶端發送Client Hello消息，消息中的會話ID設置為計划重用的會話的ID。
    2. SSL服務器如果允許重用該會話，則通過在Server Hello消息中設置相同的會話ID來應答。這樣，SSL客戶端和SSL服務器就可以利用原有會話的密鑰和加密套件，不必重新協商。
    3. SSL客戶端發送Change Cipher Spec消息，通知SSL服務器后續報文將采用原有會話的密鑰和加密套件進行加密和MAC計算。
    4. SSL客戶端計算已交互的握手消息的Hash值，利用原有會話的密鑰和加密套件處理Hash值，並通過Finished消息發送給SSL服務器，以便SSL服務器判斷密鑰和加密套件是否正確。
    5. 同樣地，SSL服務器發送Change Cipher Spec消息，通知SSL客戶端后續報文將采用原有會話的密鑰和加密套件進行加密和MAC計算。
    6. SSL服務器計算已交互的握手消息的Hash值，利用原有會話的密鑰和加密套件處理Hash值，並通過Finished消息發送給SSL客戶端，以便SSL客戶端判斷密鑰和加密套件是否正確。

1.2.6  兩階段生效模式

基本原理

兩階段生效模式，就是通過兩個階段的操作過程配置才能生效。如圖1-14所示，兩階段生效模式分兩個步驟進行：

圖1-14  兩階段生效模式的步驟示意圖

1. 第一階段用戶輸入配置命令，系統在候選數據集中進行數據類型、用戶級別、操作對象檢查，同時進行重復配置檢查。對於語法或者語義錯誤的配置語句，系統將在終端上顯示提示信息，提醒用戶配置錯誤及錯誤原因。

2. 第二階段用戶提交配置，系統進入配置的提交階段。系統提交候選數據集中的配置到運行數據集。

   • 如果業務生效成功，系統將該配置合並到運行數據集。

   • 如果業務生效失敗，系統將提示用戶配置錯誤的信息。用戶可以重新輸入配置命令修改配置，然后重新提交。

兩階段生效模式中的幾個概念如下：

• 運行數據集

  系統當前運行的配置的集合。

• 候選數據集

  在兩階段生效模式的功能中，系統為每一位用戶在設備的內存中創建運行數據集的鏡像，即候選數據集。用戶可以在其中進行配置編輯，確認編輯完成后，將配置提交至運行數據集。

合法性檢查

用戶在進入系統視圖后，系統為每個用戶分配一個候選數據集。用戶在分配的候選數據集中進行配置，同時系統基於當前用戶的配置，進行合法性檢查。

兩階段生效模式可以檢查配置是否合法，並提示用戶錯誤信息。合法性的檢查包括如下幾項：

• 重復的配置

  系統會檢測候選數據集中的配置是否與運行數據集中的一致。

  • 如果一致，則系統無需提交，並且提示有哪些重復的配置命令。

  • 如果不一致，則系統提交用戶的配置至運行數據集。

• 數據類型不合法

• 用戶級別無權執行某些命令

• 操作的對象不存在

多用戶並行執行

如圖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 等）、配置回退點時間戳以及注釋信息。
• 配置回退點內容的查看：用戶可以查看某配置回退點中所進行的配置，而且用戶還可以查看當前配置和若干次配置前的配置差異，由此可以分析如果執行回退，可能變化的配置有哪些，從而確定執行是否執行配置回退，以及如果配置回退會對系統產生造成哪些影響。
• 配置回退：用戶可以指定從當前配置回退到哪個回退點，從指定的回退點到當前配置這個過程中用戶的配置變更都會被回退。例如，創建的配置會被刪除、刪除的配置會被重新創建、修改的配置會被改回原值。
• 刪除較早的配置回退點：用戶刪除系統中最早生成的配置回退點，可清除系統中無用的信息，節省系統資源（比如磁盤空間）。

實現流程

配置回退的實現由以下幾個步驟組成：

1. 用戶下發配置回退請求，並指明配置回退點。
2. 系統檢查回退點是否合法，經過權限驗證后執行配置回退事務。
3. 系統讀取當前配置與歷史配置點的配置差異，並以逆序的方式將其逆配置操作保存。
4. 系統執行所有逆操作過程，替換當前運行配置，最后使得業務生效。

使用價值

配置回退功能在配置安全性與系統可維護性方面給用戶帶來了更大的方便，具體如下：

• 命令行用戶由於誤操作，刪除了系統中的業務配置，比如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	-