ssh之所以能夠保證安全，原因在於它採用了公鑰加密。
整個過程是這樣的：
遠端主機收到使用者的登入請求，把自己的公鑰發給使用者。
使用者使用這個公鑰，將登入密碼加密後，傳送回來。
遠端主機用自己的私鑰，解密登入密碼，如果密碼正確，就同意使用者登入。
如果中間人在使用者第二個步驟獲取到這個請求，這個請求裡面就包括了公鑰加密密碼後的字元資訊。中間人傳送這個請求到遠端主機，遠端主機就會用自己的私鑰解密然後驗證成功。請問這思路是正確的嗎，如果是這樣ssh還會是安全的嗎？
正文
我在知乎收集計算機網路、網路安全的問題整整三年，終於明白為什麼很多學生始終無法入門的原因，那是因為看到「假」的書。西安看兵馬俑的遊客，稍不留意就會被帶入乙個山寨版的秦始皇兵馬俑，渾然不知看的竟然是假的兵馬俑。
對於想以網路安全為職業的讀者，最好去閱讀權威的rfc文件，儘管剛開始會困難一點，但是至少不會走到了乙個錯誤的地方。如果覺得讀rfc實在困難，那就看看我的文章。我幫大家理理思路，等有一天大家有能力自學了，可以再去翻閱權威文件，那是走向另乙個職業高度必然的選擇！
ssh是乙個什麼樣的存在？
ssh類似於tls，站在tcp 埠22上，tls站在tcp 埠443上。
所以，這兩者是平起平坐的，都可以提供安全加密服務。對ssh不熟悉的同學，可以用tls的知識來學習ssh。
網路安全有乙個經典口號，不造輪子，只使用輪子！
什麼意思呢？
私自造輪子，本來想提供安全的通訊，可是考慮不周全，引入了更多的安全漏洞，得不償失。
使用酒精考驗的輪子，經歷了全人類不斷捶打的輪子，使用起來更放心！
所以，ssh和tls儘管名稱不同，安全的三要素是相同的套路。
ssh與tls認證方式有一點區別，tls採用第三方ca認證，而ssh為了簡化，沒有採用第三方的ca，而是採用雙方互相認證。
ssh公鑰認證
當客戶端與伺服器完成tcp三次握手，緊接著就是ssh雙方開始了握手協商的過程。
伺服器會將自己的公鑰以明文的方式推送給客戶端，為了避免被第三方篡改，公鑰的尾部報文還附帶伺服器私鑰的簽名保護。
客戶端獲得伺服器的公鑰，用公鑰解密簽名，可以解開，說明公鑰完好。解不開說明公鑰被篡改。
這裡有乙個問題，客戶端永遠都不知道公鑰是不是伺服器的，對嗎？
伺服器出示一張名片，上面赫然寫著「馬雲」，客戶端就相信這個是馬雲了？
客戶端儘管傻，但是設計ssh人並不傻，設計人員是這麼想的。
假如客戶端與伺服器第一次通訊，是在乙個安全的區域網裡，雙方如同在乙個小會議室見面，然後雙方交換名片，以後雙方即使在網際網路上通訊，依然只認在小會議室交換的名片，是不是就可以避免被第三方欺騙？
這是乙個好主意，ssh其實也是這麼用的，希望使用者第一次登入ssh伺服器，要處在乙個安全的區域網環境。完成了伺服器認證，接下來的過程和tls沒有任何區別，可以使用rsa分發金鑰、dhe分發金鑰，然後雙方就可以愉快地通訊了！
重放攻擊
所謂重放攻擊，就是第三方捕獲了雙方的歷史通訊報文，在合適的時間重新傳送一次或多次不等。
如何防止重放攻擊？
安全協議為了應對這個挑戰，通常會在報文頭里嵌入乙個序列號，從0開始單向增長的整數，接收方維護著乙個類似tcp滑動視窗，不在視窗以內的序列號統統拋棄。即使在視窗內，也要比較接收序列號與快取的序列號是否相同，如果相同，一樣拋棄處理！
寫這樣沒有幾個人能看懂的文章，不會有幾個贊。但我還是寫了，因為讀者群裡有一部分嚮往安全的朋友，必須掌握這些基礎知識！看不懂的同學也不要氣餒，羅馬不是一天建成的，只要堅持看，一定可以看懂的！
防重放攻擊
以前總是通過timestamp來防止重放攻擊，但是這樣並不能保證每次請求都是一次性的。今天看到了一篇文章介紹的通過nonce number used once 來保證一次有效，感覺兩者結合一下，就能達到乙個非常好的效果了。重放攻擊是計算機世界黑客常用的攻擊方式之一，所謂重放攻擊就是攻擊者傳送乙個目的...
js重放攻擊
正常訪問這個網頁的話是沒有任何的問題的 如果使用requsets不帶有cookie的訪問 就會出現這樣的現象 此時，我們實用charles來打斷點，修改攜帶的引數，看看改變什麼會導致出現這樣的結果 在charles對目標 進行打完 斷點之後。我們重新整理網頁，修改請求資訊，來觀察資訊變化 我們把co...
C 如何防止重放攻擊
重放攻擊 重放攻擊是指黑客通過抓包的方式，得到客戶端的請求資料及請求連線，重複的向伺服器傳送請求的行為。比如你有乙個 購買 的操作，當你點選購買按鈕時，向伺服器傳送購買的請求。而這時黑客對你的請求進行了抓包，得到了你的傳輸資料。因為你填寫的都是真實有效的資料，是可以購買成功的，因此他不用做任何改變，...