SSH如何防御重放攻擊？

SSH是一個什么樣的存在？

SSH類似于TLS，站在TCP 端口22上，TLS站在TCP 端口443上。

所以，這兩者是平起平坐的，都可以提供安全加密服務。對SSH不熟悉的同學，可以用TLS的知識來學習SSH。

網絡安全有一個經典口號，不造輪子，只使用輪子！

什么意思呢？

私自造輪子，本來想提供安全的通信，可是考慮不周全，引入了更多的安全漏洞，得不償失。

使用酒精考驗的輪子，經歷了全人類不斷捶打的輪子，使用起來更放心！

所以，SSH和TLS盡管名稱不同，安全的三要素是相同的套路。

SSH與TLS認證方式有一點區別，TLS采用第三方CA認證，而SSH為了簡化，沒有采用第三方的CA，而是采用雙方互相認證。

SSH公鑰認證

當客戶端與服務器完成TCP三次握手，緊接著就是SSH雙方開始了握手協商的過程。

服務器會將自己的公鑰以明文的方式推送給客戶端，為了避免被第三方篡改，公鑰的尾部報文還附帶服務器私鑰的簽名保護。

客戶端獲得服務器的公鑰，用公鑰解密簽名，可以解開，說明公鑰完好。解不開說明公鑰被篡改。

這里有一個問題，客戶端永遠都不知道公鑰是不是服務器的，對嗎？

服務器出示一張名片，上面赫然寫著“馬云”，客戶端就相信這個是馬云了？

客戶端盡管傻，但是設計SSH人并不傻，設計人員是這么想的。

假如客戶端與服務器第一次通信，是在一個安全的局域網里，雙方如同在一個小會議室見面，然后雙方交換名片，以后雙方即使在互聯網上通信，依然只認在小會議室交換的名片，是不是就可以避免被第三方欺騙？

重放攻擊

所謂重放攻擊，就是第三方捕獲了雙方的歷史通信報文，在合適的時間重新發送一次或多次不等。

如何防止重放攻擊？

安全協議為了應對這個挑戰，通常會在報文頭里嵌入一個序列號，從0開始單向增長的整數，接收方維護著一個類似TCP滑動窗口，不在窗口以內的序列號統統拋棄。即使在窗口內，也要比較接收序列號與緩存的序列號是否相同，如果相同，一樣拋棄處理！