但是對於在各個 IT 領域的人們，我們需要將這個事情提高一個層面。我們需要使用像 SSH 密鑰這樣的加密秘鑰，而不只是密碼。
設想一個場景：我有一個運行在雲上的服務器，用作我的主 git 庫。我有很多台工作電腦，所有這些電腦都需要登錄到這個中央服務器去做 push 與 pull 操作。這裡我設置 git 使用 SSH。當 git 使用 SSH 時，git 實際上是以 SSH 的方式登錄到服務器，就好像你通過 SSH 命令打開一個服務器的命令行一樣。為了把這些配置好，我在我的 .ssh 目錄下創建一個配置文件，其中包含一個有服務器名字、主機名、登錄用戶、密鑰文件路徑等信息的主機項。之後我可以通過輸入如下命令來測試這個配置是否正確。
ssh gitserver
很快我就可以訪問到服務器的 bash shell。現在我可以配置 git 使用相同配置項以及存儲的密鑰來登錄服務器。這很簡單，只是有一個問題：對於每一個我要用它登錄服務器的電腦，我都需要有一個密鑰文件，那意味著需要密鑰文件會放在很多地方。我會在當前這台電腦上存儲這些密鑰文件，我的其他電腦也都需要存儲這些。就像那些有特別多的密碼的用戶一樣，我們這些 IT 人員也被這些特別多的密鑰文件淹沒。怎麼辦呢？
清理在我們開始幫助你管理密鑰之前，你需要有一些密鑰應該怎麼使用的基礎知識，以及明白我們下面的提問的意義所在。同時，有個前提，也是最重要的，你應該知道你的公鑰和私鑰該放在哪裡。然後假設你應該知道：
這裡有一個例子。當你在亞馬遜的網絡服務上創建一個雲服務器，你必須提供一個用於連接你的服務器的 SSH 密鑰。每個密鑰都有一個公開的部分（公鑰）和私密的部分（私鑰）。你要想讓你的服務器安全，乍看之下你可能應該將你的私鑰放到服務器上，同時你自己帶著公鑰。畢竟，你不想你的服務器被公開訪問，對嗎？但是實際上的做法正好是相反的。
你應該把自己的公鑰放到 AWS 服務器，同時你持有用於登錄服務器的私鑰。你需要保護好私鑰，並讓它處於你的控制之中，而不是放在一些遠程服務器上，正如上圖中所示。
原因如下：如果公鑰被其他人知道了，它們不能用於登錄服務器，因為他們沒有私鑰。進一步說，如果有人成功攻入你的服務器，他們所能找到的只是公鑰，他們不可以從公鑰生成私鑰。同時，如果你在其他的服務器上使用了相同的公鑰，他們不可以使用它去登錄別的電腦。
這就是為什麼你要把你自己的公鑰放到你的服務器上以便通過 SSH 登錄這些服務器。你持有這些私鑰，不要讓這些私鑰脫離你的控制。
但是還有一點麻煩。試想一下我 git 服務器的例子。我需要做一些抉擇。有時我登錄架設在別的地方的開發服務器，而在開發服務器上，我需要連接我的 git 服務器。如何使我的開發服務器連接 git 服務器？顯然是通過使用私鑰，但這樣就會有問題。在該場景中，需要我把私鑰放置到一個架設在別的地方的服務器上，這相當危險。
一個進一步的場景：如果我要使用一個密鑰去登錄許多的服務器，怎麼辦？如果一個入侵者得到這個私鑰，這個人就能用這個私鑰得到整個服務器網絡的權限，這可能帶來一些嚴重的破壞，這非常糟糕。
同時，這也帶來了另外一個問題，我真的應該在這些其他服務器上使用相同的密鑰嗎？因為我剛才描述的，那會非常危險的。
最後，這聽起來有些混亂，但是確實有一些簡單的解決方案。讓我們有條理地組織一下。
（注意，除了登錄服務器，還有很多地方需要私鑰密鑰，但是我提出的這個場景可以向你展示當你使用密鑰時你所面對的問題。）
常規口令當你創建你的密鑰時，你可以選擇是否包含一個密鑰使用時的口令。有了這個口令，私鑰文件本身就會被口令所加密。例如，如果你有一個公鑰存儲在服務器上，同時你使用私鑰去登錄服務器的時候，你會被提示輸入該口令。沒有口令，這個密鑰是無法使用的。或者你也可以配置你的密鑰不需要口令，然後只需要密鑰文件就可以登錄服務器了。
一般來說，不使用口令對於用戶來說是更方便的，但是在很多情況下我強烈建議使用口令，原因是，如果私鑰文件被偷了，偷密鑰的人仍然不可以使用它，除非他或者她可以找到口令。在理論上，這個將節省你很多時間，因為你可以在攻擊者發現口令之前，從服務器上刪除公鑰文件，從而保護你的系統。當然還有一些使用口令的其它原因，但是在很多場合這個原因對我來說更有價值。（舉一個例子，我的 Android 平板上有 VNC 軟件。平板上有我的密鑰。如果我的平板被偷了之後，我會馬上從服務器上刪除公鑰，使得它的私鑰沒有作用，無論有沒有口令。）但是在一些情況下我不使用口令，是因為我正在登錄的服務器上沒有什麼有價值的數據，這取決於情境。
服務器基礎設施你如何設計自己服務器的基礎設施將會影響到你如何管理你的密鑰。例如，如果你有很多用戶登錄，你將需要決定每個用戶是否需要一個單獨的密鑰。（一般來說，應該如此；你不會想在用戶之間共享私鑰。那樣當一個用戶離開組織或者失去信任時，你可以刪除那個用戶的公鑰，而不需要必須給其他人生成新的密鑰。相似地，通過共享密鑰，他們能以其他人的身份登錄，這就更糟糕了。）但是另外一個問題是你如何配置你的服務器。舉例來說，你是否使用像 Puppet 這樣工具配置大量的服務器？你是否基於你自己的鏡像創建大量的服務器？當你復制你的服務器，是否每一個的密鑰都一樣？不同的雲服務器軟件允許你配置如何選擇；你可以讓這些服務器使用相同的密鑰，也可以給每一個服務器生成一個新的密鑰。
如果你在操作這些復制的服務器，如果用戶需要使用不同的密鑰登錄兩個不同但是大部分都一樣的系統，它可能導致混淆。但是另一方面，服務器共享相同的密鑰會有安全風險。或者，第三，如果你的密鑰有除了登錄之外的需要（比如掛載加密的驅動），那麼你會在很多地方需要相同的密鑰。正如你所看到的，你是否需要在不同的服務器上使用相同的密鑰不是我能為你做的決定；這其中有權衡，你需要自己去決定什麼是最好的。
最終，你可能會有：
（如果你正在別的情況下使用密鑰，這個同樣的普適理論也能應用於如何使用密鑰，需要多少密鑰，它們是否共享，你如何處理公私鑰等方面。）
安全方法了解你的基礎設施和特有的情況，你需要組合一個密鑰管理方案，它會指導你如何去分發和存儲你的密鑰。比如，正如我之前提到的，如果我的平板被偷了，我會從我服務器上刪除公鑰，我希望這在平板在用於訪問服務器之前完成。同樣的，我會在我的整體計劃中考慮以下內容：
在你的情況中，你可能決定你不想在自己經常登錄的系統上使用口令；比如，這個系統可能是一個開發者一天登錄多次的測試機器。這沒有問題，但是你需要調整一點你的規則。你可以添加一條規則：不可以通過移動設備登錄該機器。換句話說，你需要根據自己的狀況構建你的准則，不要假設某個方案放之四海而皆准。
軟件至於軟件，令人吃驚的是，現實世界中並沒有很多好的、可靠的存儲和管理私鑰的軟件解決方案。但是應該有嗎？考慮下這個，如果你有一個程序存儲你所有服務器的全部密鑰，並且這個程序被一個快捷的密鑰鎖住，那麼你的密鑰就真的安全了嗎？或者類似的，如果你的密鑰被放置在你的硬盤上，用於 SSH 程序快速訪問，密鑰管理軟件是否真正提供了任何保護嗎？
但是對於整體基礎設施和創建/管理公鑰來說，有許多的解決方案。我已經提到了 Puppet，在 Puppet 的世界中，你可以創建模塊以不同的方式管理你的服務器。這個想法是服務器是動態的，而且不需要精確地復制彼此。這裡有一個聰明的方法，在不同的服務器上使用相同的密鑰，但是對於每一個用戶使用不同的 Puppet 模塊。這個方案可能適合你，也可能不適合你。
或者，另一個選擇就是完全換個不同的檔位。在 Docker 的世界中，你可以采取一個不同的方式，正如關於 SSH 和 Docker 博客所描述的那樣。
但是怎麼樣管理私鑰？如果你搜索過的話，你無法找到很多可以選擇的軟件，原因我之前提到過；私鑰存放在你的硬盤上，一個管理軟件可能無法提到更多額外的安全。但是我使用這種方法來管理我的密鑰：
首先，我的 .ssh/config 文件中有很多的主機項。我要登錄的都有一個主機項，但是有時我對於一個單獨的主機有不止一項。如果我有很多登錄方式，就會出現這種情況。對於放置我的 git 庫的服務器來說，我有兩個不同的登錄項；一個限制於 git，另一個用於一般用途的 bash 訪問。這個為 git 設置的登錄選項在機器上有極大的限制。還記得我之前說的我存儲在遠程開發機器上的 git 密鑰嗎？好了。雖然這些密鑰可以登錄到我其中一個服務器，但是使用的賬號是被嚴格限制的。
其次，大部分的私鑰都包含口令。（對於需要多次輸入口令的情況，考慮使用 ssh-agent。）
再次，我有一些我想要更加小心地保護的服務器，我不會把這些主機項放在我的 host 文件中。這更加接近於社會工程方面，密鑰文件還在，但是可能需要攻擊者花費更長的時間去找到這個密鑰文件，分析出來它們對應的機器。在這種情況下，我就需要手動打出來一條長長的 SSH 命令。（沒那麼可怕。）
同時你可以看出來我沒有使用任何特別的軟件去管理這些私鑰。
我們偶爾會在 linux.com 收到一些問題，詢問管理密鑰的好軟件的建議。但是退一步看，這個問題事實上需要重新思考，因為沒有一個普適的解決方案。你問的問題應該基於你自己的情景。你是否簡單地嘗試找到一個位置去存儲你的密鑰文件？你是否尋找一個方法去管理多用戶問題，其中每個人都需要將他們自己的公鑰插入到 authorized_keys文件中？
通過這篇文章，我已經囊括了這方面的基礎知識，希望到此你明白如何管理你的密鑰，並且，只有當你問出了正確的問題，無論你尋找任何軟件（甚至你需要另外的軟件），它都會出現。
原文來自：https://linux.cn/article-7557-1.html
轉載地址：http://www.linuxprobe.com/linux-key-best.html
http://xxxxxx/Linuxjc/1155993.html TechArticle
