我要說的是，他們的建議不是很可靠，除非您使用的密鑰太小了-在這種情況下，您會遇到另一個問題。

一個2048位密鑰，根據大多數估計，即使不超過2020年，也可以確保您的安全。如果您使用的是1024位或更少的密鑰，則低於標準值，我建議立即更新為2048位。如果您當前正在使用1536位密鑰，則應該安全一兩年。

當然，從學術上講，這都是安全的。

正如您所鏈接的問題中提到的那樣，利弊各有千秋。

好處

• 為攻擊者減少破解密鑰的時間。如果無論如何您都使用合理的密鑰大小，那將是一個有爭議的問題。不太可能，但未知。
• 使您有機會增加密鑰大小，使其領先於曲線。

缺點 p除非您使用的是非常小的密鑰，否則>

• 並沒有真正為您提供防止密鑰破解的任何具體保護。
• 針對瀏覽器的SSL檢查/反MitM插件可能會警告用戶，密鑰已更改。在我看來，這是一個薄弱的缺點-大多數用戶不會使用它。
• 與更嚴格的 HSTS政策和實施有關的內容可能會引起臨時警告。
li>
• 這需要工作。您可能還會做其他事情。

因此，從兩方面來看，都有一些薄弱的原因，並且可能需要考慮一些極端情況。只要您使用2048位或更高版本的密鑰，我就會稍微傾向於“除非您需要”，否則不要傾斜。

最重要的是要問他們為什麼認為有必要-可能是您有一個與基礎架構相關的原因來更新我們不知道的密鑰。如果他們不能提出一個可靠的論點（“為什麼不正確”是不正確的），那麼他們應該適當地重新評估他們的建議。

更改私鑰不是最佳做法，而是廣泛使用做法；實際上，它與安全性幾乎沒有關係，而與通用CA處理證書更新的方式有很多關係，即，大多數情況下，CA就像新證書一樣使用新的私鑰生成。在CA端 較為簡單，無需為續訂做任何特殊的事情。因此，有改變密鑰的習慣。視圖。或者，更確切地說，更改SSH服務器密鑰有點不方便，因為它會破壞客戶端的 .ssh / known_hosts 文件。因此，習慣上避免更改SSH服務器密鑰。因此，SSH服務器密鑰是長期存在的。沒有人真正跳過這一點。他們為什麼要擔心具有類似加密強度的SSL密鑰？

最佳實踐是在技術進步使您的密鑰有些脆弱時，考慮到普遍的偏執狂來更改密鑰（通常稱為“出於合規性原因”）；因此，您應該考慮立即在2013年將1024位RSA密鑰替換為更長的密鑰，即使我們仍然無法破解這樣的密鑰。如果您的RSA密鑰是1536位或更寬，則沒有密碼理由要創建一個新密鑰（但是再次，也許在CA端更方便地更改它）。

答案不是技術上的或加密的，而是關於人的。有了工作變更（聽不到心煩的管理員？），服務器遷移，災難恢復測試，備份以及諸如私鑰之類的事情，便可能會暴露出來。

鑑於上述情況，密鑰更新是一種安全性最佳實踐。

不用擔心有人將您的RSA密鑰分解。對於州級對手來說，分解1024位RSA密鑰可能是可能的，但是即使對他們來說，這可能也不划算。 2048位密鑰分解可能要幾十年才能實現。

我主要擔心的是您的私鑰在服務器漏洞中被盜。由於攻擊者可能在您的服務器上存在持久性惡意軟件，因此在過去的入侵中獲得的收益還不清楚。因此，您需要重新安裝服務器以保護新密鑰。

另一個問題是，某些弱SSL套件（主要是基於 RSA 加密的家族）會使用較長的SSL套件。術語密鑰用於保密，而不僅僅是用於身份驗證。有了這些妥協，您的服務器密鑰就可以解密與使用這種弱套件的服務器之間過去的所有SSL通信。使用新密鑰並安全刪除舊密鑰可以限制這種攻擊的影響。

因此，如果您的服務器仍啟用了這些套件，則強烈建議您定期更改密鑰。

• 您在HeartBleed之後更改了密鑰嗎？
• 您的數據中心技術人員對不良硬盤有何處理？
• 去年有人離開了運營組織嗎？ ？
• 上次旋轉管理員密碼和ssh密鑰是什麼時候？

所有這些問題應該使您開始思考密鑰的完整性。我並不是說它們很可能已受到損害，或者任何人都將能夠濫用它們。我正在嘗試讓您考慮為什麼要旋轉它們。

旋轉鍵應該超級容易，並且是一種很好的安全保護措施。如果您因為困難而沒有這樣做，那就是一個嚴重的問題。構建工具和流程以使其變得容易。如果不這樣做，您將最終無法旋轉更重要的事情。

使用密鑰的次數越多，給予攻擊者的時間就越多。儘管目前的技術認為不可能打破2048位，但是要格外謹慎，更換鑰匙也不是一件壞事。

此外，有人可能會設法獲取您的私鑰，而您卻無法檢測到它。如果他不能重複該動作，那麼續約的好處就非常明顯。

雖然我同意每次續簽證書都沒有技術上的理由來生成新密鑰，但我不會立即向您的安全團隊/經理提出挑戰，並就此問題打電話給他們。

與產生新密鑰同樣有效的非技術原因。例如，在大型組織中，IT集中化，技能，過程和良好實踐的級別各不相同，因此集中化的安全管理區域可能需要此類實踐來幫助減輕某些風險，這也可以幫助使過程變得越來越小可管理的。儘管從技術角度來看，更複雜的程序可能更正確，但它們更難以記錄，並且使員工更難於知道他們正確地遵循了這些程序。如果這種做法不會產生大量開銷，那麼採用和維護更簡單的“始終執行X”方法可能會更容易。

從另一個角度考慮。您組織中負責管理證書的每個人對您的問題是否有相同的意識和了解，並且他們是否認真/專心？員工更替的水平是多少？在何種程度上需要關注前員工可能訪問的敏感數據的數量。

每當考慮安全性時，人為因素幾乎總是與技術方面一樣重要或更重要政策和程序需要考慮人的因素，並試圖確保這些政策和程序的結構能夠幫助員工正確地做事，即使他們可能不完全理解為什麼需要這樣做。 / p>

SP 800-57第1部分修訂，密鑰管理建議

NIST關於RSA密碼週期的建議似乎為1-2年。

這實際上與更改密碼相同。如果有人在更改密碼時正在破解您的密碼，則他們必須重新開始。或者，如果密碼或私鑰被盜，則續訂會使他們的被盜密鑰失效（假設他們無法輕易再次竊取它）。

每次更改私鑰都是一個好習慣一年或每隔幾年，以便您知道它在需要更改時不會損壞任何東西，但是對於證書本身的安全性而言，這不是必需的。

許多人提出了以下事實：ssh主機密鑰很少作為不旋轉ssl密鑰的參數而旋轉。這似乎是另一個要解決的問題。 （我為一個稍微偏離主題的答案表示歉意，但是這裡有人提到它，因此似乎很合適）。

請參閱上面的答案，以為什麼一個可能想要旋轉鍵的鍵。

對於出於合規性原因而需要旋轉ssh主機密鑰但擔心可用性對最終用戶造成影響的所有人，以下內容將特別有用。

1）部署一個ssh_ca（man ssh-keygen中非常完整的說明）

  ssh-keygen -f ssh_ca -b 4096  

2）將證書分發給用戶：將證書授權行添加到〜/ .ssh / known_hosts

  @ cert-authority * .domain.name ssh-rsa AAAAB3 [...] ==註釋 

3）簽名主機密鑰（確保將每個主機密鑰限制為單個主機）

  ssh-keygen -s ssh_ca -I host.domain.name -h -n host.domain .name -V + 52w /etc/ssh/ssh_host_rsa_key.pub

4）配置服務器以顯示證書（/ etc / ssh / sshd_config）：

  HostCertificate / etc / ss h / ssh_host_rsa_key-cert.pub  

客戶端現在信任由CA簽名的任何主機密鑰（不再在您第一次連接時盲目接受密鑰信號）

此是一個很好的參考。 該項目創建了一些有用的工具，用於使用ssh_ca自動終止用戶訪問權限。