SSH 協(xié)議原理、組成、認證方式和過程

概述

SSH是(Secure SHell protocol) 的簡寫,安全外殼協(xié)議(SSH)是一種在不安全網(wǎng)絡(luò)上提供安全遠程登錄及其它安全網(wǎng)絡(luò)服務(wù)的協(xié)議。  
  OpenSSH 是SSH (Secure SHell)協(xié)議的免費開源實現(xiàn)。SSH協(xié)議族可以用來進行遠程控制,或在計算機之間傳送文件。而實現(xiàn)此功能的傳統(tǒng)方式,如telnet(終端仿真協(xié)議)、 rcp ftp、 rlogin、rsh都是極為不安全的,并且會使用明文傳送密碼。OpenSSH提供了服務(wù)端后臺程序和客戶端工具,用來加密遠程控件和文件傳輸過程的中的數(shù)據(jù),并由此來代替原來的類似服務(wù)。
  在過去我們使用的rsh和telnet,因為包括登錄時的ID和密碼數(shù)據(jù)沒有加密就傳到網(wǎng)絡(luò)上,存在安全上的問題。即使在內(nèi)部網(wǎng)上,也有在因特網(wǎng)上的竊取和篡改等危險性。SSH將包括密碼在內(nèi)的所有數(shù)據(jù)都已進行了加密處理,可以進行更安全的遠程操作。在SSH中,由于協(xié)議標準的不同而存在SSH1和SSH2兩個不同的版本。SSH2是為了回避SSH1所使用的加密算法的許可證問題而開發(fā)的(現(xiàn)在這一許可證問題已經(jīng)不存在了)。TLES 8中作為安裝SSH協(xié)議的應(yīng)用程序采用了開放源碼的OpenSSH。OpenSSH與SSH1和SSH2的任何一個協(xié)議都能對應(yīng),但默認使用SSH2。

更詳細的說明以及安裝使用,請參考官網(wǎng):http://www.openssh.com/

主要功能

  • 類似 telnet 的遠程聯(lián)機使用 shell 的服務(wù)器,即 ssh。
  • 類似 FTP 服務(wù)的 sftp-server ,提供更安全的 FTP 服務(wù)。
SSH 功能

工作原理

ssh 工作原理
  1. 服務(wù)器建立公鑰: 每一次啟動 sshd 服務(wù)時,該服務(wù)會主動去找 /etc/ssh/ssh_host* 的文件,若系統(tǒng)剛剛安裝完成時,由于沒有這些公鑰,因此 sshd 會主動去計算出這些需要的公鑰,同時也會計算出服務(wù)器自己需要的私鑰。
  • 客戶端主動聯(lián)機請求: 若客戶端想要聯(lián)機到 ssh 服務(wù)器,則需要使用適當?shù)目蛻舳顺绦騺砺?lián)機,包括 ssh, putty 等客戶端程序連接。
  • 服務(wù)器傳送公鑰給客戶端: 接收到客戶端的要求后,服務(wù)器便將第一個步驟取得的公鑰傳送給客戶端使用 (此時應(yīng)是明碼傳送,反正公鑰本來就是給大家使用的)。
  • 客戶端記錄并比對服務(wù)器的公鑰數(shù)據(jù)及隨機計算自己的公私鑰: 若客戶端第一次連接到此服務(wù)器,則會將服務(wù)器的公鑰記錄到客戶端的用戶家目錄內(nèi)的 ~/.ssh/known_hosts 。若是已經(jīng)記錄過該服務(wù)器的公鑰,則客戶端會去比對此次接收到的與之前的記錄是否有差異。若接受此公鑰, 則開始計算客戶端自己的公私鑰。
  • 回傳客戶端的公鑰到服務(wù)器端: 用戶將自己的公鑰傳送給服務(wù)器。此時服務(wù)器:具有服務(wù)器的私鑰與客戶端的公鑰,而客戶端則是: 具有服務(wù)器的公鑰以及客戶端自己的私鑰,你會看到,在此次聯(lián)機的服務(wù)器與客戶端的密鑰系統(tǒng) (公鑰+私鑰) 并不一樣,所以才稱為非對稱加密系統(tǒng)。
  • 開始雙向加解密: (1)服務(wù)器到客戶端:服務(wù)器傳送數(shù)據(jù)時,拿用戶的公鑰加密后送出??蛻舳私邮蘸螅米约旱乃借€解密 (2)客戶端到服務(wù)器:客戶端傳送數(shù)據(jù)時,拿服務(wù)器的公鑰加密后送出。服務(wù)器接收后,用服務(wù)器的私鑰解密,這樣就能保證通信安全。

組成

SSH 主要有三部分組成:

  1. 傳輸層協(xié)議 [SSH-TRANS] 提供了服務(wù)器認證,保密性及完整性。此外它有時還提供壓縮功能。 SSH-TRANS 通常運行在 TCP/IP連接上,也可能用于其它可靠數(shù)據(jù)流上。 SSH-TRANS 提供了強力的加密技術(shù)、密碼主機認證及完整性保護。該協(xié)議中的認證基于主機,并且該協(xié)議不執(zhí)行用戶認證。更高層的用戶認證協(xié)議可以設(shè)計為在此協(xié)議之上。
  • 用戶認證協(xié)議 [SSH-USERAUTH] 用于向服務(wù)器提供客戶端用戶鑒別功能。它運行在傳輸層協(xié)議 SSH-TRANS 上面。當 SSH-USERAUTH 開始后,它從低層協(xié)議那里接收會話標識符(從第一次密鑰交換中的交換哈希 H )。會話標識符唯一標識此會話并且適用于標記以證明私鑰的所有權(quán)。 SSH-USERAUTH 也需要知道低層協(xié)議是否提供保密性保護。
  • 連接協(xié)議 [SSH-CONNECT] 將多個加密隧道分成邏輯通道。它運行在用戶認證協(xié)議上。它提供了交互式登錄話路、遠程命令執(zhí)行、轉(zhuǎn)發(fā) TCP/IP 連接和轉(zhuǎn)發(fā) X11 連接。
      一旦建立一個安全傳輸層連接,客戶機就發(fā)送一個服務(wù)請求。當用戶認證完成之后,會發(fā)送第二個服務(wù)請求。這樣就允許新定義的協(xié)議可以與上述協(xié)議共存。連接協(xié)議提供了用途廣泛的各種通道,有標準的方法用于建立安全交互式會話外殼和轉(zhuǎn)發(fā)(“隧道技術(shù)”)專有 TCP/IP 端口和 X11 連接。
      通過使用SSH,你可以把所有傳輸?shù)臄?shù)據(jù)進行加密,這樣"中間人"這種攻擊方式就不可能實現(xiàn)了,而且也能夠防止DNS欺騙和IP欺騙。使用SSH,還有一個額外的好處就是傳輸?shù)臄?shù)據(jù)是經(jīng)過壓縮的,所以可以加快傳輸?shù)乃俣?。SSH有很多功能,它既可以代替Telnet,又可以為FTP、PoP、甚至為PPP提供一個安全的"通道"。
  • 傳輸層協(xié)議(The Transport Layer Protocol)提供服務(wù)器認證,數(shù)據(jù)機密性,信息完整性 等的支持;
  • 用戶認證協(xié)議(The User Authentication Protocol) 則為服務(wù)器提供客戶端的身份鑒別;
  • 連接協(xié)議(The Connection Protocol) 將加密的信息隧道復(fù)用成若干個邏輯通道,提供給更高層的應(yīng)用協(xié)議使用; 各種高層應(yīng)用協(xié)議可以相對地獨立于SSH基本體系之外,并依靠這個基本框架,通過連接協(xié)議使用SSH的安全機制。

同時SSH協(xié)議框架中還為許多高層的網(wǎng)絡(luò)安全應(yīng)用協(xié)議提供擴展的支持。它們之間的層次關(guān)系可以用如下圖來表示:

SSH協(xié)議框架

認證方式

  • 基于口令的認證:這個就不用說了,就是輸入用戶名和密碼
  • 基于密鑰的認證,具體步驟如下:
      (1).客戶端建立兩把鑰匙(公鑰與私鑰)
      (2).將公鑰數(shù)據(jù)上傳到服務(wù)器上
      (3).將公鑰放置服務(wù)器端的正確目錄與文件名(scp 或 ssh-copy-id)

對于SSH這樣以提供安全通訊為目標的協(xié)議,其中必不可少的就是一套完備的密鑰機制。由于SSH協(xié)議是面向互聯(lián)網(wǎng)網(wǎng)絡(luò)中主機之間的互訪與信息交換,所以主機密鑰成為基本的密鑰機制。也就是說,SSH協(xié)議要求每一個使用本協(xié)議的主機都必須至少有一個自己的主機密鑰對,服務(wù)方通過對客戶方主機密鑰的認證之后,才能允許其連接請求。一個主機可以使用多個密鑰,針對不同的密鑰算法而擁有不同的密鑰,但是至少有一種是必備的,即通過 DSS算法產(chǎn)生的密鑰。關(guān)于DSS算法,請參考FIPS-186 文檔.SSH協(xié)議關(guān)于主機密鑰認證的管理方案有兩種,如下圖所示:

SSH主機密鑰認證

  每一個主機都必須有自己的主機密鑰,密鑰可以有多對,每一對主機密鑰對包括公開密鑰和私有密鑰。在實際應(yīng)用過程中怎樣使用這些密鑰,并依賴它們來實現(xiàn)安全特性呢?如上圖所示,SSH協(xié)議框架中提出了兩種方案。
  在第一種方案中,主機將自己的公用密鑰分發(fā)給相關(guān)的客戶機,客戶機在訪問主機時則使用該主機的公開密鑰來加密數(shù)據(jù),主機則使用自己的私有密鑰來解密數(shù)據(jù),從而實現(xiàn)主機密鑰認證,確定客戶機的可靠身份。在圖2(a)中可以看到,用戶從主機A上發(fā)起操作,去訪問,主機B和主機C,此時,A成為客戶機,它必須事先配置主機B和主機C的公開密鑰,在訪問的時候根據(jù)主機名來查找相應(yīng)的公開密鑰。對于被訪問主機(也就是服務(wù)器端)來說則只要保證安全地存儲自己的私有密鑰就可以了。 
  在第二種方案中,存在一個密鑰認證中心,所有系統(tǒng)中提供服務(wù)的主機都將自己的公開密鑰提交給認證中心,而任何作為客戶機的主機則只要保存一份認證中心的公開密鑰就可以了。在這種模式下,客戶機在訪問服務(wù)器主機之前,還必須向密鑰認證中心請求認證,認證之后才能夠正確地連接到目的主機上。
  很顯然,第一種方式比較容易實現(xiàn),但是客戶機關(guān)于密鑰的維護卻是個麻煩事,因為每次變更都必須在客戶機上有所體現(xiàn);第二種方式比較完美地解決管理維護問題,然而這樣的模式對認證中心的要求很高,在互聯(lián)網(wǎng)絡(luò)上要實現(xiàn)這樣的集中認證,單單是權(quán)威機構(gòu)的確定就是個大麻煩,有誰能夠什么都能說了算呢?但是從長遠的發(fā)展來看,在企業(yè)應(yīng)用和商業(yè)應(yīng)用領(lǐng)域,采用中心認證的方案是必要的。
  另外,SSH協(xié)議框架中還允許對主機密鑰的一個折中處理,那就是首次訪問免認證。首次訪問免認證是指,在某客戶機第一次訪問主機時,主機不檢查主機密鑰,而向該客戶都發(fā)放一個公開密鑰的拷貝,這樣在以后的訪問中則必須使用該密鑰,否則會被認為非法而拒絕其訪問。

工作過程

在整個通訊過程中,為實現(xiàn) SSH的安全連接,服務(wù)器端與客戶端要經(jīng)歷如下五個階段:
* 版本號協(xié)商階段,SSH目前包括 SSH1和SSH2兩個版本, 雙方通過版本協(xié)商確定使用的版本
* 密鑰和算法協(xié)商階段,SSH支持多種加密算法, 雙方根據(jù)本端和對端支持的算法,協(xié)商出最終使用的算法
* 認證階段,SSH客戶端向服務(wù)器端發(fā)起認證請求, 服務(wù)器端對客戶端進行認證
* 會話請求階段, 認證通過后,客戶端向服務(wù)器端發(fā)送會話請求
* 交互會話階段 ,會話請求通過后,服務(wù)器端和客戶端進行信息的交互

  1. 版本號協(xié)商階段
      1. 服務(wù)器打開端口 22,等待客戶端連接。
      2. 客戶端向服務(wù)器端發(fā)起 TCP初始連接請求,TCP連接建立后,服務(wù)器向客戶端發(fā)送第一個報文,包括版本標志字符串,格式為“SSH-<主協(xié)議版本號>.<次協(xié)議版本號>-<軟件版本號>”,協(xié)議版本號由主版本號和次版本號組成,軟件版本號主要是為調(diào)試使用。
      3. 客戶端收到報文后,解析該數(shù)據(jù)包,如果服務(wù)器端的協(xié)議版本號比自己的低,且客戶端能支持服務(wù)器端的低版本,就使用服務(wù)器端的低版本協(xié)議號,否則使用自己的協(xié)議版本號。
      4. 客戶端回應(yīng)服務(wù)器一個報文,包含了客戶端決定使用的協(xié)議版本號。服務(wù)器比較客戶端發(fā)來的版本號,決定是否能同客戶端一起工作。
      5. 如果協(xié)商成功,則進入密鑰和算法協(xié)商階段,否則服務(wù)器端斷開 TCP連接。

Note: 版本號協(xié)商階段報文都是采用明文方式傳輸?shù)摹?/p>

  • 密鑰和算法協(xié)商階段
      1. 服務(wù)器端和客戶端分別發(fā)送算法協(xié)商報文給對端,報文中包含自己支持的公鑰算法列表、加密算法列表、MAC(Message Authentication Code,消息驗證碼)算法列表、壓縮算法列表等;
      2. 服務(wù)器端和客戶端根據(jù)對端和本端支持的算法列表得出最終使用的算法。
      3. 服務(wù)器端和客戶端利用 DH交換(Diffie-Hellman Exchange)算法、主機密鑰對等參數(shù),生成會話密鑰和會話 ID。

    通過以上步驟,服務(wù)器端和客戶端就取得了相同的會話密鑰和會話ID。
        * 對于后續(xù)傳輸?shù)臄?shù)據(jù),兩端都會使用會話密鑰進行加密和解密,保證了數(shù)據(jù)傳送的安全
        * 在認證階段,兩端會使用會話 ID用于認證過程。
    

Note:
  在協(xié)商階段之前,服務(wù)器端已經(jīng)生成 RSA或 DSA密鑰對,他們主要用于參與會話密鑰的生成。

  • 認證階段
      1. 客戶端向服務(wù)器端發(fā)送認證請求,認證請求中包含用戶名、認證方法、與該認證方法相關(guān)的內(nèi)容(如:password認證時,內(nèi)容為密碼)。
      2. 服務(wù)器端對客戶端進行認證,如果認證失敗,則向客戶端發(fā)送認證失敗消息,其中包含可以再次認證的方法列表。
      3. 客戶端從認證方法列表中選取一種認證方法再次進行認證。
      4. 該過程反復(fù)進行, 直到認證成功或者認證次數(shù)達到上限, 服務(wù)器關(guān)閉連接為止。

SSH提供兩種認證方式:
  1. password認證:客戶端向服務(wù)器發(fā)出 password認證請求,將用戶名和密碼加密后發(fā)送給服務(wù)器;服務(wù)器將該信息解密后得到用戶名和密碼的明文,與設(shè)備上保存的用戶名和密碼進行比較,并返回認證成功或失敗的消息。
  2. publickey 認證:采用數(shù)字簽名的方法來認證客戶端。目前,設(shè)備上可以利用RSA和 DSA兩種公共密鑰算法實現(xiàn)數(shù)字簽名。客戶端發(fā)送包含用戶名、公共密鑰和公共密鑰算法的 publickey 認證請求給服務(wù)器端。服務(wù)器對公鑰進行合法性檢查,如果不合法,則直接發(fā)送失敗消息;否則,服務(wù)器利用數(shù)字簽名對客戶端進行認證,并返回認證成功或失敗的消息
SSH2.0還提供了 password-publickey 認證和 any 認證:
  1. password-publickey 認證:指定該用戶的認證方式為 password 和 publickey認證同時滿足。客戶端版本為 SSH1的用戶只要通過其中一種認證即可登錄;客戶端版本為 SSH2的用戶必須兩種認證都通過才能登錄。
  2. any認證:指定該用戶的認證方式可以是 password,也可以是 publickey。

  • 會話請求階段

    1. 服務(wù)器等待客戶端的請求;
    2. 認證通過后,客戶端向服務(wù)器發(fā)送會話請求;
    3. 服務(wù)器處理客戶端的請求。請求被成功處理后, 服務(wù)器會向客戶端回應(yīng) SSH_SMSG_SUCCESS包,SSH進入交互會話階段;否則回應(yīng) SSH_SMSG_FAILURE包,表示服務(wù)器處理請求失敗或者不能識別請求。
  • 交互會話階段
    在這個模式下,數(shù)據(jù)被雙向傳送:
      1. 客戶端將要執(zhí)行的命令加密后傳給服務(wù)器;
      2. 服務(wù)器接收到報文,解密后執(zhí)行該命令,將執(zhí)行的結(jié)果加密發(fā)還給客戶端;
      3. 客戶端將接收到的結(jié)果解密后顯示到終端上.

SSH Q&A

Q1: SSH的版本和區(qū)別。
  SSH2避免了RSA的專利問題,并修補了CRC的缺陷。SSH2用數(shù)字簽名算法(DSA)和Diffie-Hellman(DH)算法代替RSA來完成對稱密鑰的交換,用HMAC來代替CRC。同時SSH2增加了AES和Twofish等對稱加密算法。
  A1: SSH(Secure SHell)到目前為止有兩個不兼容的版本——SSH1和SSH2。SSH1又分為1.3和1.5兩個版本。SSH1采用DES、3DES、 Blowfish和RC4等對稱加密算法保護數(shù)據(jù)安全傳輸,而對稱加密算法的密鑰是通過非對稱加密算法(RSA)來完成交換的。SSH1使用循環(huán)冗余校驗碼(CRC)來保證數(shù)據(jù)的完整性,但是后來發(fā)現(xiàn)這種方法有缺陷。
更多內(nèi)容請參考The SSHv1 Protocol & The SSHv2 Protocol

Q2: 什么是HMAC?
  A2: HMAC(Hash Message Authentication Code) ,散列消息鑒別碼,基于密鑰的Hash算法的認證協(xié)議。消息鑒別碼實現(xiàn)鑒別的原理是,用公開函數(shù)和密鑰產(chǎn)生一個固定長度的值作為認證標識,用這個標識鑒別消息的完整性。使用一個密鑰生成一個固定大小的小數(shù)據(jù)塊,即MAC,并將其加入到消息中,然后傳輸。接收方利用與發(fā)送方共享的密鑰進行鑒別認證等。

Q3: 什么是X11 forwarding?
  A3: sh的X11 forwarding特性可以使X client和X server安全地通訊。使用X11 forwarding后,從X client到X Server方向的數(shù)據(jù)先被送至ssh server,ssh server利用和ssh client的安全通道轉(zhuǎn)發(fā)給ssh client,再由ssh client轉(zhuǎn)發(fā)給X server,從X server到X client的數(shù)據(jù)流同理。這里ssh server和ssh client充當了X client和X server間數(shù)據(jù)的轉(zhuǎn)發(fā)器,由于ssh server和X client、ssh client和X server一般在同一臺機器上,它們之間是一種安全的進程間通訊,而ssh server和ssh client間的通訊也是安全的,所以X client和X server間的通訊就是安全的。

Q4: 什么是TTY?
  A4: 終端是一種字符型設(shè)備,它有多種類型,通常使用tty來簡稱各種類型的終端設(shè)備。tty是 Teletype的縮寫。Teletype是最早出現(xiàn)的一種終端設(shè)備,很象電傳打字機,是由Teletype公司生產(chǎn)的。設(shè)備名放在特殊文件目錄/dev/下。

Q5: 簡單描述下SSH運行的過程?

A5:簡要過程如下
* Client端向Server端發(fā)起SSH連接請求。
* Server端向Client端發(fā)起版本協(xié)商。
* 協(xié)商結(jié)束后Server端發(fā)送Host Key公鑰 Server Key公鑰,隨機數(shù)等信息。到這里所有通信是不加密的。
* Client端返回確認信息,同時附帶用公鑰加密過的一個隨機數(shù),用于雙方計算Session Key。
* 進入認證階段。從此以后所有通信均加密。
* 認證成功后,進入交互階段。
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • Spring Cloud為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見模式的工具(例如配置管理,服務(wù)發(fā)現(xiàn),斷路器,智...
    卡卡羅2017閱讀 136,554評論 19 139
  • 互聯(lián)網(wǎng)的通信安全,建立在SSL/TLS協(xié)議之上。 本文簡要介紹SSL/TLS協(xié)議的運行機制。文章的重點是設(shè)計思想和...
    拉肚閱讀 2,995評論 0 6
  • 1.OkHttp源碼解析(一):OKHttp初階2 OkHttp源碼解析(二):OkHttp連接的"前戲"——HT...
    隔壁老李頭閱讀 21,573評論 24 176
  • 一、作用 不使用SSL/TLS的HTTP通信,就是不加密的通信。所有信息明文傳播,帶來了三大風(fēng)險。 (1)竊聽風(fēng)險...
    XLsn0w閱讀 11,053評論 2 44
  • 清嫻的感恩日記第二天9.21 1.首先特別感恩大羅先生,喊我起床一起練習(xí)太極,今天又學(xué)了一式,為你的精進負責(zé)點贊。...
    清嫻516閱讀 248評論 0 0

友情鏈接更多精彩內(nèi)容