在 《使用wireshark分析ssh口令登錄細(xì)節(jié)》 和 《ssh工具，開發(fā)者必須有所了解》 這兩篇文章中，我們知道了SSH登錄有兩種登錄驗(yàn)證方式，其中口令登錄方式使用簡(jiǎn)單，但會(huì)遇到安全問(wèn)題，比如遇到中間人攻擊，就會(huì)泄漏服務(wù)器的root口令。所以從安全的角度來(lái)看，建議使用另外一種登錄驗(yàn)證方式，這就是密鑰對(duì)登錄方式。
創(chuàng)新互聯(lián)建站自2013年創(chuàng)立以來(lái)，先為自貢等服務(wù)建站，自貢等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為自貢企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。
密鑰對(duì)驗(yàn)證方式對(duì)于初學(xué)者來(lái)說(shuō)并不是很友好，所以我分兩篇文章把這個(gè)事情說(shuō)清楚，本文主要從原理的角度講解，讓你了解這種方式運(yùn)作的流程，下一篇從實(shí)戰(zhàn)的角度手把手教你登錄ssh服務(wù)器。
對(duì)于開發(fā)者來(lái)說(shuō)，也請(qǐng)務(wù)必學(xué)會(huì)使用密鑰對(duì)方式登錄服務(wù)器，因?yàn)楝F(xiàn)在很多應(yīng)用和服務(wù)推薦這種方式，比如Github就可以使用密鑰對(duì)方式連接，AWS默認(rèn)就禁止口令登錄。
網(wǎng)上有很多文章介紹ssh口令登錄，但客觀的說(shuō)，很多文章講錯(cuò)了。
很多人大概是這樣理解的，客戶端生成一個(gè)公開密碼學(xué)算法的密鑰對(duì)（注意不是ssh服務(wù)器端的密鑰對(duì)），然后將公鑰放到ssh服務(wù)器上的 authorized_keys 文件中（潛臺(tái)詞就是你有ssh權(quán)限才能操作）。
然后ssh如何登錄呢?在連接過(guò)程中，會(huì)將客戶端密鑰對(duì)的公鑰發(fā)送給ssh服務(wù)器，服務(wù)器在 authorized_keys 文件中匹配到這個(gè)公鑰，就認(rèn)為登錄成功了，其實(shí)這個(gè)理解是有問(wèn)題的。
核心的兩個(gè)問(wèn)題：
知道了這個(gè)結(jié)論后，我們看看詳細(xì)的登錄驗(yàn)證過(guò)程，在 《使用wireshark分析ssh口令登錄細(xì)節(jié)》 中說(shuō)過(guò)，ssh登錄分為兩個(gè)階段，不管是哪一種登錄驗(yàn)證，第一階段的過(guò)程都是相同的，區(qū)別在于第二階段。
有的同學(xué)說(shuō)，這次你為啥不用wireshark分析了？因?yàn)榈诙A段的消息傳遞都是加密保護(hù)的，并不能解密出具體的消息格式，這一點(diǎn)和TLS協(xié)議非常不同，TLS協(xié)議有多種方式可以解密出明文，而SSH協(xié)議是不支持的，所以wireshark只能顯示密文。
基于這一點(diǎn)，本文就不用wireshark分析了，簡(jiǎn)單談一談ssh密鑰對(duì)登錄的流程，要經(jīng)過(guò)多個(gè)消息交互。
第二階段具體的流程如下：
1：ssh客戶端生成一個(gè) key ID（這個(gè)ID是基于密鑰對(duì)的公鑰算出來(lái)的，具體格式未知），再一次說(shuō)明，這個(gè)密鑰對(duì)不是服務(wù)器的，使用會(huì)話密鑰加密后發(fā)送給服務(wù)器端。
2：服務(wù)器端從 authorized_keys 文件中匹配 key ID，如果匹配，此時(shí)還不能證明這個(gè)ssh客戶端是真正的客戶端密鑰對(duì)的主人。
3：服務(wù)器端生成一個(gè)隨機(jī)數(shù)，然后用客戶端的公鑰加密后發(fā)送給客戶端。
4：客戶端使用自己的私鑰解密出服務(wù)器端的隨機(jī)數(shù)，注意，如果某個(gè)攻擊者僅僅有客戶端的公鑰，它是無(wú)法解密出的，因?yàn)楣粽邲]有對(duì)應(yīng)的私鑰。
5：為了向服務(wù)器端證明它能解密出這個(gè)隨機(jī)數(shù)，客戶端將解密出的隨機(jī)數(shù)用會(huì)話密鑰加密，將得到的值進(jìn)行MD5運(yùn)算。然后將這個(gè)值發(fā)送給服務(wù)器，以便響應(yīng)（4）階段的消息。
6：服務(wù)器端對(duì)原始隨機(jī)數(shù)也使用會(huì)話密鑰加密，再進(jìn)行MD5計(jì)算，如果得出的值和（5）階段客戶端發(fā)送的一致，代表雙方的登錄校驗(yàn)通過(guò)。
服務(wù)器端使用服務(wù)器密鑰對(duì)公鑰指紋像客戶端證明它就是真正的服務(wù)器端；而客戶端使用它自己的密鑰對(duì)向服務(wù)器證明它就是真實(shí)的客戶端。
由于在驗(yàn)證過(guò)程中，客戶端密鑰對(duì)的公鑰不會(huì)傳輸，所以即使遇到中間人攻擊，攻擊者也不會(huì)獲取到公鑰（不考慮客戶端機(jī)器本身遇到攻擊了）。
如果客戶端的公鑰曾經(jīng)泄漏過(guò)，攻擊者也不能成功登錄ssh服務(wù)器，原因是攻擊者沒有私鑰，無(wú)法解密出隨機(jī)數(shù)，從而不能完成驗(yàn)證。
當(dāng)然如果客戶端密鑰對(duì)公鑰和私鑰全部泄漏了，那就當(dāng)我什么也沒說(shuō)，所以定期更換密鑰對(duì)還是有好處的。
基于以上兩點(diǎn)，我認(rèn)為ssh密鑰對(duì)登錄是安全的，也是推薦的。
不會(huì)的，
SSH 為建立在應(yīng)用層和傳輸層基礎(chǔ)上的安全協(xié)議。SSH 是目前較可靠，專為遠(yuǎn)程登錄會(huì)話和其他網(wǎng)絡(luò)服務(wù)提供安全性的協(xié)議。利用 SSH 協(xié)議可以有效防止遠(yuǎn)程管理過(guò)程中的信息泄露問(wèn)題。
使用ssh密鑰連接git服務(wù)器相對(duì)于賬號(hào)密碼來(lái)說(shuō)會(huì)安全一丟丟，密鑰不丟問(wèn)題不大。而且很git服務(wù)提供商如：github、gitee等都提供ssh密鑰訪問(wèn)，可以自己設(shè)定密鑰。這樣就可以把不同平臺(tái)設(shè)置成同一個(gè)密鑰，然后就可以一個(gè)密鑰訪問(wèn)所有的git服務(wù)器。
下面以github為例。
如果已有密鑰跳過(guò)這一步。如果沒有密鑰,可以用ssh-keygen來(lái)生成
找到TortoiseGit安裝目錄的 bin/pageant.exe ，啟動(dòng)，并添加私鑰匙文件
從github項(xiàng)目中，獲取ssh地址
直接Clone這個(gè)地址就可以了直接clone了
重慶分公司
重慶分公司
