ssh密鑰對登錄安全嗎？實踐篇

在上一篇文章 《ssh密鑰對登錄安全嗎？原理篇》 了解了ssh密鑰對登錄原理后，接下去就是實踐的問題了，這是大部分人更關(guān)心的知識，其中也有一些隱藏的陷阱。

在張家界等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站制作、成都網(wǎng)站設(shè)計 網(wǎng)站設(shè)計制作定制制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站設(shè)計,網(wǎng)絡(luò)營銷推廣,成都外貿(mào)網(wǎng)站建設(shè)公司,張家界網(wǎng)站建設(shè)費用合理。

首先 要生成一對密鑰對，ssh-keygen 是 ssh 工具集中的一個工具，用于生成密鑰對：

-b 是密鑰對的長度，越長越安全，但運算速度就會相應(yīng)變慢，在這個例子中生成的是一個 RSA 密鑰對，其中 id_rsa 是公鑰（也可以自定義名字），公鑰也叫做 identity 文件，需要放到 ssh 服務(wù)器 ~/.ssh/authorized_keys 文件中（其中 ~ 符號表示想要以那個屬主用戶的身份（比如 root 用戶）登錄ssh服務(wù)器），用于證明這個密鑰對擁有訪問 ssh 服務(wù)器的權(quán)限。

在 ssh 登錄的時候，ssh 客戶端需要讀取公鑰文件，但不會傳輸。

那么 passphrase 是什么呢？是一個口令，用于保護密鑰對，有了口令，即使密鑰對文件泄漏了，由于攻擊者沒有口令解密，那么密鑰對仍然是安全的。

如果圖省事，口令可以為空，如果不為空，則ssh登錄的時候需要輸入口令。

運行完成后，生成的密鑰對默認會保存到客戶端屬主目錄 ~/.ssh 下，為什么生成在這個目錄呢？因為登錄驗證的時候 ssh 客戶端會讀取屬主目錄下的公鑰文件。

接下去查看生成的密鑰對文件，運行如下命令：

id_rsa.pub 文件就是公鑰，id_rsa 是私鑰，需要注意的就是這二個文件的權(quán)限問題，私鑰權(quán)限必須是 600，嚴格限制權(quán)限，而 id_rsa 權(quán)限可以適當(dāng)放大，對于客戶端，~/.ssh 的目錄權(quán)限不會影響 ssh 登錄，但從安全的角度看，請保持 700 權(quán)限。

公鑰文件上傳到ssh服務(wù)器后，其實就可以刪除了，因為私鑰包含公鑰。

接下去 就是要將公鑰放到 ssh 服務(wù)器上，一般有三種方法：

1：ssh-copy-id

ssh-copy-id 工具專門用于將公鑰上傳到ssh服務(wù)器的authorized_keys文件中，這個工具通過口令登錄的方式上傳公鑰，運行很簡單：

ssh-copy-id 默認會上傳 ~/.ssh/ 目錄下公鑰文件（即 identity 文件 ），ssh服務(wù)器上可能有多個用戶，那上傳到那個用戶的.ssh目錄下呢？這根據(jù) username 而定，比如 /home/username 目錄。

如果 identity 文件不在 ~/.ssh 目錄下或者名稱不是默認的 id_rsa ，也可以通過 -i 參數(shù)指定文件，比如：

如果ssh服務(wù)器上的 ssh 打開 StrictModes 嚴格模式，這個工具會更改ssh服務(wù)上的 ~/.ssh目錄， ~/.ssh/authorized_keys 文件的權(quán)限。

重點要注意的是，ssh服務(wù)器用戶的.ssh目錄必須是700 權(quán)限，authorized_keys 文件也必須是 700 權(quán)限，否則 ssh 登錄驗證會失敗，下面會重點描述這個問題。

2：手動上傳公鑰

如果ssh服務(wù)器關(guān)閉了口令登錄方式，就必須使用這種方式了，重點要注意權(quán)限問題。

首先拷貝 ~/.ssh/id_rsa.pub 內(nèi)容，然后登錄到ssh服務(wù)器上，再將剪貼板的內(nèi)容粘帖到 ~/.ssh/uthorized_keys 文件中（如果不存在就創(chuàng)建對應(yīng)的目錄和文件）

最后運行下列命令:

盡量保證目錄和文件只有對應(yīng)的ssh用戶才能訪問，否則ssh登錄會失敗，原因就是為了保障安全，你總不希望自己的公鑰被ssh服務(wù)器上的其他用戶看到把？

3：使用ssh口令登錄方式手動上傳公鑰

如果機器上沒有 ssh-copy-id 工具（Windows 10 原生 ssh 客戶端就沒有），可采用這種方式，其實也很簡單，就一條命令，但能讓你了解詳細的工作過程，所以比較推薦這種方式：

最后 就是 ssh 登錄服務(wù)器，驗證自己的公鑰是否成功上傳了，執(zhí)行下列命令：

當(dāng)然也可以指定私鑰文件，比如 ：

如果登錄的時候還是讓你輸入口令，則很有可能是ssh服務(wù)器上的 ~/.ssh/authorized_keys 權(quán)限有問題，請檢查下。

如果還是遇到登錄失敗的問題，可以在ssh服務(wù)器上查看日志，比如：

相關(guān)文章：

root用密鑰登陸夠安全嗎

使用密鑰登錄可以提高服務(wù)器安全性，因為密鑰不容易被破解和竊取。與使用密碼登錄不同，密鑰不會在網(wǎng)絡(luò)上傳輸，從而避免了密碼被竊取的風(fēng)險。此外，使用密碼登錄需要輸入明文密碼，極易被攻擊者截獲。而使用密鑰登錄則消除了這一風(fēng)險。如果使用密鑰登錄，被破解的機會將會小得多，并且使攻擊者無法強制使用某個特定的密碼進行登錄。總之，使用密鑰登錄比使用密碼登錄更加安全。

ssh密鑰對登錄安全嗎？原理篇

在 《使用wireshark分析ssh口令登錄細節(jié)》 和 《ssh工具，開發(fā)者必須有所了解》 這兩篇文章中，我們知道了SSH登錄有兩種登錄驗證方式，其中口令登錄方式使用簡單，但會遇到安全問題，比如遇到中間人攻擊，就會泄漏服務(wù)器的root口令。所以從安全的角度來看，建議使用另外一種登錄驗證方式，這就是密鑰對登錄方式。

密鑰對驗證方式對于初學(xué)者來說并不是很友好，所以我分兩篇文章把這個事情說清楚，本文主要從原理的角度講解，讓你了解這種方式運作的流程，下一篇從實戰(zhàn)的角度手把手教你登錄ssh服務(wù)器。

對于開發(fā)者來說，也請務(wù)必學(xué)會使用密鑰對方式登錄服務(wù)器，因為現(xiàn)在很多應(yīng)用和服務(wù)推薦這種方式，比如Github就可以使用密鑰對方式連接，AWS默認就禁止口令登錄。

網(wǎng)上有很多文章介紹ssh口令登錄，但客觀的說，很多文章講錯了。

很多人大概是這樣理解的，客戶端生成一個公開密碼學(xué)算法的密鑰對（注意不是ssh服務(wù)器端的密鑰對），然后將公鑰放到ssh服務(wù)器上的 authorized_keys 文件中（潛臺詞就是你有ssh權(quán)限才能操作）。

然后ssh如何登錄呢?在連接過程中，會將客戶端密鑰對的公鑰發(fā)送給ssh服務(wù)器，服務(wù)器在 authorized_keys 文件中匹配到這個公鑰，就認為登錄成功了，其實這個理解是有問題的。

核心的兩個問題：

知道了這個結(jié)論后，我們看看詳細的登錄驗證過程，在 《使用wireshark分析ssh口令登錄細節(jié)》 中說過，ssh登錄分為兩個階段，不管是哪一種登錄驗證，第一階段的過程都是相同的，區(qū)別在于第二階段。

有的同學(xué)說，這次你為啥不用wireshark分析了？因為第二階段的消息傳遞都是加密保護的，并不能解密出具體的消息格式，這一點和TLS協(xié)議非常不同，TLS協(xié)議有多種方式可以解密出明文，而SSH協(xié)議是不支持的，所以wireshark只能顯示密文。

基于這一點，本文就不用wireshark分析了，簡單談一談ssh密鑰對登錄的流程，要經(jīng)過多個消息交互。

第二階段具體的流程如下：

1：ssh客戶端生成一個 key ID（這個ID是基于密鑰對的公鑰算出來的，具體格式未知），再一次說明，這個密鑰對不是服務(wù)器的，使用會話密鑰加密后發(fā)送給服務(wù)器端。

2：服務(wù)器端從 authorized_keys 文件中匹配 key ID，如果匹配，此時還不能證明這個ssh客戶端是真正的客戶端密鑰對的主人。

3：服務(wù)器端生成一個隨機數(shù)，然后用客戶端的公鑰加密后發(fā)送給客戶端。

4：客戶端使用自己的私鑰解密出服務(wù)器端的隨機數(shù)，注意，如果某個攻擊者僅僅有客戶端的公鑰，它是無法解密出的，因為攻擊者沒有對應(yīng)的私鑰。

5：為了向服務(wù)器端證明它能解密出這個隨機數(shù)，客戶端將解密出的隨機數(shù)用會話密鑰加密，將得到的值進行MD5運算。然后將這個值發(fā)送給服務(wù)器，以便響應(yīng)（4）階段的消息。

6：服務(wù)器端對原始隨機數(shù)也使用會話密鑰加密，再進行MD5計算，如果得出的值和（5）階段客戶端發(fā)送的一致，代表雙方的登錄校驗通過。

服務(wù)器端使用服務(wù)器密鑰對公鑰指紋像客戶端證明它就是真正的服務(wù)器端；而客戶端使用它自己的密鑰對向服務(wù)器證明它就是真實的客戶端。

由于在驗證過程中，客戶端密鑰對的公鑰不會傳輸，所以即使遇到中間人攻擊，攻擊者也不會獲取到公鑰（不考慮客戶端機器本身遇到攻擊了）。

如果客戶端的公鑰曾經(jīng)泄漏過，攻擊者也不能成功登錄ssh服務(wù)器，原因是攻擊者沒有私鑰，無法解密出隨機數(shù)，從而不能完成驗證。

當(dāng)然如果客戶端密鑰對公鑰和私鑰全部泄漏了，那就當(dāng)我什么也沒說，所以定期更換密鑰對還是有好處的。

基于以上兩點，我認為ssh密鑰對登錄是安全的，也是推薦的。

秘鑰、公鑰匙、認證之間的關(guān)系 DES、RSA、AES 數(shù)據(jù)加密傳輸

對稱加密是最快速、最簡單的一種加密方式，加密（encryption）與解密（decryption）用的是同樣的密鑰（secret key）。對稱加密有很多種算法，由于它效率很高，所以被廣泛使用在很多加密協(xié)議的核心當(dāng)中。

對稱加密通常使用的是相對較小的密鑰，一般小于256 bit。因為密鑰越大，加密越強，但加密與解密的過程越慢。如果你只用1 bit來做這個密鑰，那黑客們可以先試著用0來解密，不行的話就再用1解；但如果你的密鑰有1 MB大，黑客們可能永遠也無法破解，但加密和解密的過程要花費很長的時間。密鑰的大小既要照顧到安全性，也要照顧到效率，是一個trade-off。

對稱加密的一大缺點是密鑰的管理與分配，換句話說，如何把密鑰發(fā)送到需要解密你的消息的人的手里是一個問題。在發(fā)送密鑰的過程中，密鑰有很大的風(fēng)險會被黑客們攔截?，F(xiàn)實中通常的做法是將對稱加密的密鑰進行非對稱加密，然后傳送給需要它的人。

常用的有：DES、AES

非對稱加密為數(shù)據(jù)的加密與解密提供了一個非常安全的方法，它使用了一對密鑰，公鑰（public key）和私鑰（private key）。私鑰只能由一方安全保管，不能外泄，而公鑰則可以發(fā)給任何請求它的人。非對稱加密使用這對密鑰中的一個進行加密，而解密則需要另一個密鑰。比如，你向銀行請求公鑰，銀行將公鑰發(fā)給你，你使用公鑰對消息加密，那么只有私鑰的持有人--銀行才能對你的消息解密。與對稱加密不同的是，銀行不需要將私鑰通過網(wǎng)絡(luò)發(fā)送出去，因此安全性大大提高。

常用的有：RSA

（1） 對稱加密加密與解密使用的是同樣的密鑰，所以速度快，但由于需要將密鑰在網(wǎng)絡(luò)傳輸，所以安全性不高。

（2） 非對稱加密使用了一對密鑰，公鑰與私鑰，所以安全性高，但加密與解密速度慢。

（3） 解決的辦法是將對稱加密的密鑰使用非對稱加密的公鑰進行加密，然后發(fā)送出去，接收方使用私鑰進行解密得到對稱加密的密鑰，然后雙方可以使用對稱加密來進行溝通。

在現(xiàn)代密碼體制中加密和解密是采用不同的密鑰（公開密鑰），也就是非對稱密鑰密碼系統(tǒng)，每個通信方均需要兩個密鑰，即公鑰和私鑰，這兩把密鑰可以互為加解密。公鑰是公開的，不需要保密，而私鑰是由個人自己持有，并且必須妥善保管和注意保密。

公鑰私鑰的原則：

非對稱密鑰密碼的主要應(yīng)用就是公鑰加密和公鑰認證，而公鑰加密的過程和公鑰認證的過程是不一樣的，下面我就詳細講解一下兩者的區(qū)別。

比如有兩個用戶Alice和Bob，Alice想把一段明文通過雙鑰加密的技術(shù)發(fā)送給Bob，Bob有一對公鑰和私鑰，那么加密解密的過程如下：

上面的過程可以用下圖表示，Alice使用Bob的公鑰進行加密，Bob用自己的私鑰進行解密。

身份認證和加密就不同了，主要用戶鑒別用戶的真?zhèn)?。這里我們只要能夠鑒別一個用戶的私鑰是正確的，就可以鑒別這個用戶的真?zhèn)巍?/p>

還是Alice和Bob這兩個用戶，Alice想讓Bob知道自己是真實的Alice，而不是假冒的，因此Alice只要使用公鑰密碼學(xué)對文件簽名發(fā)送 給Bob，Bob使用Alice的公鑰對文件進行解密，如果可以解密成功，則證明Alice的私鑰是正確的，因而就完成了對Alice的身份鑒別。整個身 份認證的過程如下：

上面的過程可以用下圖表示，Alice使用自己的私鑰加密，Bob用Alice的公鑰進行解密。

DES是Data Encryption Standard（數(shù)據(jù)加密標準）的縮寫，DES算法為密碼體制中的對稱密碼體制。它是由IBM公司研制的一種加密算法，美國國家標準局于1977年公布把它作為非機要部門使用的數(shù)據(jù)加密標準，二十年來，它一直活躍在國際保密通信的舞臺上，扮演了十分重要的角色。

DES是一個分組加密算法，他以64位為分組對數(shù)據(jù)加密。同時DES也是一個對稱算法：加密和解密用的是同一個算法。它的密匙長度是56位（因為每個第8位都用作奇偶校驗），密匙可以是任意的56位的數(shù)，而且可以任意時候改變。其中有極少量的數(shù)被認為是弱密匙，但是很容易避開他們。所以保密性依賴于密鑰。

特點：分組比較短、密鑰太短、密碼生命周期短、運算速度較慢。 DES算法具有極高安全性，到目前為止，除了用窮舉搜索法對DES算法進行攻擊外，還沒有發(fā)現(xiàn)更有效的辦法。而56位長的密鑰的窮舉空間為256，這意味著如果一臺計算機的速度是每一秒種檢測一百萬個密鑰，則它搜索完全部密鑰就需要將近2285年的時間。

DES現(xiàn)在已經(jīng)不視為一種安全的加密算法，因為它使用的56位秘鑰過短，以現(xiàn)代計算能力，24小時內(nèi)即可能被破解。也有一些分析報告提出了該算法的理論上的弱點，雖然實際情況未必出現(xiàn)。該標準在最近已經(jīng)被 高級加密標準 （AES）所取代。

高級加密標準（Advanced Encryption Standard，AES），又稱Rijndael加密法，是美國聯(lián)邦政府采用的一種區(qū)塊加密標準。這個標準用來替代原先的 DES ，已經(jīng)被多方分析且廣為全世界所使用。經(jīng)過五年的甄選流程，高級加密標準由美國國家標準與技術(shù)研究院（NIST）于2001年11月26日發(fā)布于FIPS PUB 197，并在2002年5月26日成為有效的標準。2006年，高級加密標準已然成為對稱密鑰加密中最流行的算法之一。

AES的區(qū)塊長度固定為128 位元 ，密鑰長度則可以是128，192或256位元。

RSA加密算法是一種 非對稱加密算法 。在 公鑰加密標準 和 電子商業(yè) 中RSA被廣泛使用。RSA是 1977年 由 羅納德·李維斯特 （Ron Rivest）、 阿迪·薩莫爾 （Adi Shamir）和 倫納德·阿德曼 （Leonard Adleman）一起提出的。當(dāng)時他們?nèi)硕荚?麻省理工學(xué)院 工作。RSA就是他們?nèi)诵帐祥_頭字母拼在一起組成的。

RSA算法利用兩個很大的質(zhì)數(shù)相乘所產(chǎn)生的乘積來加密。這兩個質(zhì)數(shù)無論哪一個先與原文件編碼相乘，對文件加密，均可由另一個質(zhì)數(shù)再相乘來解密。但要用一個 質(zhì)數(shù)來求出另一個質(zhì)數(shù)，則是十分困難的。因此將這一對質(zhì)數(shù)稱為密鑰對(Key Pair)。在加密應(yīng)用時，某個用戶總是將一個密鑰公開，讓需發(fā)信的人員將信息用其公共密鑰加密后發(fā)給該用戶，而一旦信息加密后，只有用該用戶一個人知道 的私用密鑰才能解密。具有數(shù)字憑證身份的人員的公共密鑰可在網(wǎng)上查到，亦可在請對方發(fā)信息時主動將公共密鑰傳給對方，這樣保證在Internet上傳輸信 息的保密和安全。

開發(fā)中：

客戶端發(fā)送的敏感數(shù)據(jù)時需要加密處理，客戶端數(shù)據(jù)采用公鑰加密，服務(wù)器用對應(yīng)的秘鑰解密，客戶端保存公鑰，服務(wù)器保存秘鑰

服務(wù)器發(fā)送的數(shù)據(jù)也要加密時，服務(wù)器端數(shù)據(jù)采用秘鑰加密，客戶端數(shù)據(jù)用對應(yīng)的公鑰加密，客戶端保存公鑰，服務(wù)器保存秘鑰

服務(wù)器要認證客戶端時，客戶端數(shù)據(jù)采用秘鑰加密，服務(wù)器用對應(yīng)的公鑰解密，客戶端保留秘鑰，服務(wù)器保留公鑰

常用加解密方案：

如果想要更加安全一點，可以在仿照微信的通信，每次都在傳輸數(shù)據(jù)上加上一個32為隨機數(shù)和并將數(shù)據(jù)按照一定的規(guī)則生成一個校驗sign

本文標題：服務(wù)器密鑰安全性 服務(wù)器2016密鑰
文章轉(zhuǎn)載：http://sd-ha.com/article22/dojsecc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、移動網(wǎng)站建設(shè)、品牌網(wǎng)站建設(shè)、域名注冊、、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)