ssh的通訊步驟主要包括建立加密通道、認證和通訊三個階段。分析下來風險主要是在建立加密通道階段，分析和應對總結如下。
階段一：協商加密通訊連線。即通過非對稱加密方式先在client和server之間安全的協商對稱金鑰（即會話金鑰）：
1）雙方協商ssh版本、採用的非對稱加密演算法等資訊；
2）server傳送公鑰給client；
3）client生成對稱金鑰（即會話金鑰）的相關引數，並用公鑰加密後發給server；
4）server基於私鑰解密資訊獲取引數，並基於金鑰交換演算法生成同樣的會話金鑰。
5）雙方後續通訊均基於此會話金鑰進行加密，從而避免金鑰被竊取風險。會話金鑰定期更新。
本階段的主要風險在於：ssh不具備ca證書機制，可能會被鏈路中間人偽造server並傳送自己的公鑰給client，而client無法確定其真實性。
解決方案：本階段（協商）完成後，client使用的客戶端會計算並顯示公鑰的sha1值，使用者可以用這個值與server服務方在公開渠道（如**）提供的公鑰的sha1值對比，以確保其真實性。
階段二：登入認證、。在會話金鑰建立的安全加密連線上，client向server發出登入請求，server進行認證。認證主要包括兩種方式：
**1）登入使用者名稱和密碼認證，即對稱金鑰方式認證。**這個很簡單，server根據資訊生成sha1值進行比對即可。
2）ssh金鑰對認證，即使用客戶端的非對稱金鑰進行認證。在前期（如使用者註冊階段）以安全的方式生成乙個客戶端的非對稱金鑰對，並將公鑰資訊配置到server端（不同登入賬戶應放到不同賬戶目錄下，具體參考： 隨後使用linux命令列或者windows ssh客戶端配置需要使用的證書路徑，即傳送金鑰對登入請求到server。server端獲取需要登入的賬號資訊後，基於非對稱金鑰啟動認證流程，確認請求的私鑰簽名正確即可成功登入。
階段三：通訊階段。
理論上階段
二、三因為都是在階段一的會話金鑰加密後進行通訊，因此除非暴力破解否則沒有安全問題。
上面過程涉及到三種金鑰：
1、建立安全通道金鑰：對稱金鑰或者非對稱金鑰。
2、真正用於會話加密的金鑰：建立安全通道的金鑰不適合用於加密。如果是非對稱金鑰，則由於效能較低不適合加密；而如果是對稱金鑰如果直接用於會話加密就會導致該金鑰一直不變，非常容易被破解（哪怕是事後破解也是暴露了金鑰資訊）。因此，真正用於會話的金鑰是由第一步建立安全通道時協商交換生成的，通常做法是增加乙個隨機數作為計算會話金鑰的因子，同時週期性更新。
3、最終登入金鑰：對稱金鑰或者非對稱金鑰，均要事先配置。
最後一點思考：
ssh和vpn通訊建立其實是有很大共同點，核心目標都是在傳輸關鍵內容前建立好安全通道，確保資料的機密性和完整性。那麼建立安全通道要考慮的關鍵點就是協商好用於加密會話的對稱金鑰。如果基於對稱金鑰，必須進行事先的配置且確保用於建立安全通道的金鑰分發絕對安全。因此，絕大部分場景下都是採用非對稱金鑰方案，不需要提前協商即可建立金鑰安全交換通道。因此，從上面的分析來看，若場景中沒有的對稱金鑰而必須採用非對稱金鑰機制，最大的威脅就來自於中間人攻擊。
避免中間人攻擊只有兩種方案：
1）在能夠控制鏈路的情況下，避免鏈路上的節點處於不可信任狀態，確保節點都可信。但這個往往很難做到。
2）採用有權威可信機構的認證方案。比如非對稱金鑰領域，需要通訊雙方有可信ca頒發的證書，從而確保雙發的公鑰都是未經中間人偽造的。
參考：
ssh 協議原理：
ssh協議認證詳解：
ssh金鑰對登入方式：
HTTPS工作原理 如何保證通訊的安全？
https在原有的http協議與tcp協議之間新增了一層，這一層初始使用的是ssl加密，後續逐漸使用tls。首先需要明白https誕生的原因 解決通訊過程中的安全問題，不會被攻擊者獲取通訊中的資訊。為了實現這一目標，我們第一想法是對通訊的內容進行加密。如對稱加密 非對稱加密等。非對稱加密安全性較高，...
如何保證執行緒安全？
執行緒安全 一般說來，確保執行緒安全的方法有這幾個 競爭與原子操作 同步與鎖 可重入 過度優化。競爭與原子操作 多個執行緒同時訪問和修改乙個資料，可能造成很嚴重的後果。出現嚴重後果的原因是很多操作被作業系統編譯為彙編 之後不止一條指令，因此在執行的時候可能執行了一半就被排程系統打斷了而去執行別的 了...
HTTPS如何保證安全
同事去大廠面試，回來帶回來乙個問題，聊聊https的安全和非對稱加密。剛好自己對這塊網路協議也不是很熟悉，剛好研究一波。https如何保證安全？https這邊主要採用了對稱加密 非對稱加密 ca認證去保證安全。當我們在網路上傳輸資訊的時候，需要確保資訊的安全，不被竊聽，不被攔截，那從最簡單的方式，就...