Linux網絡篇，ssh原理及應用

1、對稱加密與非對稱加密

    對稱加密: 加密和解密的祕鑰使用的是同一個.
    非對稱加密: 非對稱加密算法須要兩個密鑰：公開密鑰（publickey）和私有密鑰；簡稱公鑰和私鑰

對稱加密

 

 

對稱加密的密碼強度高、較難破解。可是祕鑰的保存成爲了一個重要的問題，特別是若是機羣龐大的時候，一旦某個客戶端暴露了祕鑰，會給整個系統帶來嚴重的安全問題

非對稱加密

 

 

公鑰加密後的密文，只能經過對應的私鑰進行解密。而經過公鑰推理出私鑰的可能性微乎其微。私鑰是Server端獨有，並且私鑰並不會在網絡中進行傳輸，這必定程度上保證了數據的安全性，充分利用了非對稱加密的特性

非對稱加密的過程：

① 客戶端向服務器發送請求，並獲得服務器傳來的公鑰

②-④ 客戶端利用從服務器獲得公鑰對登陸數據（用戶名和密碼或其餘驗證數據）進行加密；而後將加密後的數據傳給服務器

⑤-⑦ 服務器利用私鑰將從客戶端收到的數據進行解密。並將解密後的數據與正確數據（數據庫中存儲的用戶名和密碼或其餘）進行校驗，根據獲得校驗結果容許或拒絕這次登陸請求；並將最後結果通知客戶端
2、非對稱加密的安全性問題

從上面的分析中，咱們得知了非對稱加密確實解決了必定的安全問題，那麼它就必定安全了嗎？答案是絕對否認的。由於經過上面的分析，咱們得知客戶端對於服務器方是沒有認證的。而這時若是一個假冒的服務器方將本身的公鑰發給了客戶端，它能夠很簡單的把客戶端的加密數據進行解密，由於公鑰和私鑰都是它本身的啊。這樣客戶端的數據就被竊取了。這種攻擊方式叫作中間人攻擊。其原理以下：

 

 

3、SSH原理

由於非對稱加密體質很是耗費系統資源，所以SSH僅將非對稱加密用於登陸鏈接過程，而鏈接後的數據交互採用了對稱加密。咱們經過上面得知，即便是非對稱加密也存在一個問題——如何解決中間人攻擊？

https中針對中間人攻擊採起了公證機制——經過CA來進行公證，但是SSH的公鑰和私鑰都是本身生成的，無法公證。只能經過Client端本身對公鑰進行確認。

所以，SSH引入了known_hosts文件。客戶端的每次鏈接請求，服務器都會將相關信息與known_hosts文件中的信息進行匹配，若是是第一次鏈接，服務器會將相關信息存儲在known_hosts文件中，在這個過程當中，服務器會請求客戶端的用戶進行確認；拿什麼確認呢？公鑰指紋！什麼是公鑰指紋？

由於公鑰很長，長達1024位甚至2048位或更長，若是比較這麼長的數據會很耗費系統資源。因此這裏的公鑰指紋是指利用MD5算法對公鑰進行加密後造成的128位的一個數據；客戶端利用這個從服務器獲取到的公鑰加密後的公鑰指紋和真正服務器的公鑰（需提早獲取）加密後的公鑰指紋進行比較，若是一致的話，用戶須要輸入yes確認這次認證，若是不一致的話，有可能遭到了中間人攻擊，用戶須要輸入no對這次認證進行中斷，防止數據泄露。如圖：

 

 

若是不是第一次鏈接，客戶端（登陸方）會將本身的known_hosts文件中的公鑰指紋與服務器傳來的公鑰指紋進行對比，若是一致，鏈接會繼續，客戶端輸入用戶名和密碼直接登陸就能夠。若是不一致，客戶端會斷定這次鏈接遭到了中間人攻擊，並阻止這次鏈接，如圖：

 

 

若是是用戶主動從新部署了SSH服務器，而且確認這次鏈接無誤的話，用戶須要在客戶端（登陸方）的known_hosts文件中刪除與該地址對應的公鑰數據，從新進行SSH鏈接認證便可
4、SSH免密登陸原理

基於口令的認證方式每次登陸都須要輸入密碼，這是比較麻煩的一件事情，爲此，SSH引入了基於公鑰認證的登陸方式，這也是SSH免密登陸的依據，那麼基於公鑰認證的登陸方式具體步驟是怎樣的呢？

 

 

1.登陸端A生成公鑰和私鑰，並（手動）將公鑰追加到被登陸端B的 authorized_key 文件中

2.登陸端A向被登陸端B發送鏈接請求，並將公鑰發送給被登陸端B

3.被登陸端B接受登陸端A發來的公鑰，並將該公鑰與本身的 authorized_key 文件中的全部存儲的公鑰進行比較，若是並未發現有此公鑰存在，則登陸端A須要進行口令認證與被登陸端B進行鏈接。若是在 authorized_key 文件中找到了與登陸端A發送的公鑰相同的公鑰，則生成隨機數R，並利用公鑰加密該隨機數獲得 publickey(R)，最後被登陸端B將 publickey(R) 傳給登陸端A

4.登陸端A利用私鑰對 publickey(R) 進行解密獲得R，登陸端A和被登陸端B通訊時會產生一個會話ID(sessionKey)。登陸端A利用MD5算法將R和ID進行加密，並將加密後的數據傳給被登陸端B

5.被登陸端B也利用MD5算法對R（被登陸端B在第3步中隨機生成的）和會話ID(兩者的會話屬於同一會話，所以會話ID sessionKey是相同的)進行加密。並將加密後的數據與第四步登陸端傳來的加密數據進行比較，若是相同，則容許這次登陸端A的鏈接請求，並與之創建鏈接。若是不一樣，則兩者繼續進行基於口令認證的鏈接請求

注意：

免密登陸的任何一個環節出現不匹配時，登陸端A和被登陸端B的鏈接將會被轉換爲基於口令的認證鏈接
5、用生活實例來演示免密登陸

老闆Boss在服務器B上建立了一個userb用戶，但是他回到家後想用客戶機A使用userb用戶鏈接服務器B

首先，老闆在本身辦公室的客戶機A上建立了祕鑰，包括公鑰和私鑰。老闆把公鑰傳到公司的服務器S上；但是這個老闆不可能把公司的全部事情都包了，那樣太累了，因而他在公司的服務器S上作了一個容許訪問該服務器的  "電腦編號-各級部門經理帳號"  認證列表，該認證列表中包含了公司的全部部門經理的辦公電腦的MAC地址和其對應的不一樣級別的用戶帳號。只有被該列表包含的   "電腦編號-各級部門經理帳號"   纔有資格免密登陸此服務器進行辦公

有一天老闆想要統計公司今年的盈虧情況，因此要查看公司的帳單，老闆在客戶機A上使用SBoss登陸服務器S；當服務器S收到老闆的鏈接請求後，服務器B上的   "電腦編號-各級部門經理帳號"   會判斷本身裏邊是否有與客戶機A經過SBoss登陸服務器的認證，若是沒有的話，老闆還得輸入SBoss在服務器B上的密碼進行登陸；若是有的話，服務器B會發送一個用客戶機A上的公鑰加密的隨機數給客戶機A，客戶機A用私鑰解密這個隨機數，並用MD5算法對該隨機數和當前會話ID組合的數據進行加密，而後將加密後的數據發送給服務器S，服務器S也利用MD5算法對該隨機數和當前會話ID進行加密，並與客戶機A傳來的加密數據進行對比。根據對比結果決定是否容許這次免密登陸請求

上文中的抽象事物與ssh相關文件對應關係以下：

老闆 ===> 操做計算機用戶的相關管理人員

服務器S ===> SSH服務端

客戶端A ===> SSH客戶端

SBoss ===> SSH服務端管理員帳號

公鑰 ===> SSH客戶端的 id_rsa.pub 文件

私鑰 ===> SSH客戶端號的 id_rsa 文件

"電腦編號-各級部門經理帳號" ===> SSH服務端的 authorized_keys 文件
6、SSH免密登陸實戰
單向免密登陸方法一

1.客戶端A執行如下命令，生成祕鑰

    ssh-keygen -t rsa
     
     
    注意：一路回車便可

2.客戶端A執行如下命令，將公鑰傳給服務端B

ssh-copy-id [服務器B的IP地址]

3.客戶端A執行如下命令（注意：先不要執行它，若B出現登陸不了A的情況再執行）

ssh-add id_rsa

4.服務器A執行如下命令驗證

    ssh [服務端B IP地址]
    或
    ssh [服務端B上的用戶名]@[服務端B IP地址]

5.若是出錯的話，多是如下幾種緣由

    1.兩臺機器均設置相應的免密登陸
    2.
    chmod 700 /home/[用戶名]/.ssh/
    chmod 600 /home/[用戶名]/.ssh/authorized_keys
    3.修改/etc/ssh/ssh_config配置文件以下關鍵字
    GSSAPIAuthentication no

單向免密登陸方法二

1.客戶端A生成公鑰和祕鑰

    ssh-keygen -t rsa
     
     
    注意：
    一路回車便可

2.客戶端A將公鑰傳給服務端B

scp id_rsa.pub root@192.168.5.17:~/.ssh/

3.服務端B將A的公鑰追加到本身的 authorized_keys 文件中（若是沒有該文件，則先新建再追加）

    touch authorized_keys
    cat id_rsa.pub >> authorized_keys

4.客戶端A執行如下命令（注意：先不要執行它，若B出現登陸不了A的情況再執行）

ssh-add id_rsa

5.客戶端A登陸服務端B

ssh root@192.168.5.17

雙向免密登陸
 

1..編輯主機A和主機B的sshd配置文件   vim /etc/ssh/ssh_config

    RSAAuthentication yes
    PubkeyAuthentication yes
    AuthorizedKeysFile   .ssh/authorized_keys

2.重啓 sshd 服務

service sshd restart

3.主機A新建用戶usea，主機B新建用戶userb

    主機A的操做：
    useradd usera
    passwd usera
     
     
    主機B的操做：
    useradd userb
    passwd userb

4.主機A使用usera用戶登陸，建立ssh祕鑰

    su usera
     
    ssh-keygen -t rsa   （一直回車）

5.主機B使用userb用戶登陸，建立ssh祕鑰

    su userb
    ssh-keygen -t rsa   (一直回車)

6.主機A使用usera在  ~/.ssh/ 目錄下新建authorized_keys文件，而且將usera和userb的公鑰（id_rsa.pub）複製到該文件中

    cd ~/.ssh/
    touch authorized_keys
     
     
     
     
    將主機A的usera公鑰複製進主機A的usera的目錄下的 authorized_keys 文件
     
    cat id_rsa.pub > authorized_keys
     
     
     
    將主機B的userb公鑰追加到主機A的usera的目錄下的 authorized_keys 文件
     
    ssh userb@[主機B的IP地址] cat /home/userb/.ssh/id_rsa.pub >> authorized_keys

7.主機A使用usera用戶執行如下命令

    chmod 700 /home/usera/.ssh/
    chmod 600 /home/usera/.ssh/authorized_keys

8.將主機A的用戶usera的~/.ssh目錄下的兩個配置文件 authorized_keys、known_hosts 複製到主機B的userb用戶的~/.ssh目錄下

scp authorized_keys known_hosts userb@[主機B的IP地址]:~/.ssh/

9.主機B使用userb用戶設置指定文件權限

    chmod 700 /home/userb/.ssh/
    chmod 600 /home/userb/.ssh/authorized_keys

10.到此，主機A和B就能夠經過usera和userb經過ssh免密登陸了

    ssh userb@[主機B的IP地址]
    ssh usera@[主機A的IP地址]