一、對稱加密與非對稱加密
對稱加密: 加密和解密的秘鑰使用的是同一個.
非對稱加密: 非對稱加密演算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰；簡稱公鑰和私鑰
對稱加密
對稱加密的密碼強度高、較難破解，但是秘鑰的保存成為了一個重要的問題，特別是如果機群龐大的時候，一旦某個客戶端暴露了秘鑰，會給整個系統帶來嚴重的安全問題
非對稱加密
公鑰加密后的密文，只能通過對應的私鑰進行解密，而通過公鑰推理出私鑰的可能性微乎其微，私鑰是Server端獨有，而且私鑰并不會在網路中進行傳輸，這一定程度上保證了資料的安全性，充分利用了非對稱加密的特性
非對稱加密的程序：
① 客戶端向服務器發送請求，并得到服務器傳來的公鑰
②-④ 客戶端利用從服務器得到公鑰對登錄資料（用戶名和密碼或其他驗證資料）進行加密；然后將加密后的資料傳給服務器
⑤-⑦ 服務器利用私鑰將從客戶端收到的資料進行解密，并將解密后的資料與正確資料（資料庫中存盤的用戶名和密碼或其他）進行校驗，根據得到校驗結果允許或拒絕此次登錄請求；并將最后結果通知客戶端
二、非對稱加密的安全性問題
從上面的分析中，我們得知了非對稱加密確實解決了一定的安全問題，那么它就一定安全了嗎？答案是絕對否定的，因為通過上面的分析，我們得知客戶端對于服務器方是沒有認證的，而這時如果一個假冒的服務器方將自己的公鑰發給了客戶端，它可以很簡單的把客戶端的加密資料進行解密，因為公鑰和私鑰都是它自己的啊，這樣客戶端的資料就被竊取了，這種攻擊方式叫做中間人攻擊，其原理如下：
三、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連接認證即可
四、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的連接將會被轉換為基于口令的認證連接
五、用生活實體來演示免密登錄
老板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 檔案
六、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 [email protected]:~/.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 [email protected]
雙向免密登錄
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地址]
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/105909.html
標籤：Linux
上一篇：cobbler批量安裝系統問題