【讨論】Ansible登入憑證的選擇：是預分發公鑰免密登入，還是使用使用者名+密碼？

本文将從安全性、便捷性和可維護性三個方面探讨Ansible登入憑證的選擇問題：

1. 安全性

• 預分發公鑰到目标伺服器

優點和缺點都是一樣的，即目标環境的安全性取決于ansible所在主控端的安全性。主控端一旦被攻破，則全環境都淪陷。但假設我們可以保證主控端的安全，則目标環境的密碼設定上就可以有相當高的自由度，甚至可以完全随機獲得極高強度的密碼，而不用考慮密碼記錄和存儲的問題。主控端的安全加強目标小，也容易得多。

• 使用使用者名+密碼ssh登入

必須有地方存儲目标環境的登入資訊，且密碼須明文存儲或傳輸。這個存儲媒介可以是檔案，可以是資料庫，也可以是第三方的某個服務。 這種方法缺點與預分發公鑰是一樣的，如果密碼存儲媒介洩露或被攻破，或被通過監聽網絡通訊竊取，整個目标環境離被攻破就僅差一步了：找到并攻破一台與目标環境連通的主機。這種方法并沒有預分發公鑰的優點：如果攻擊者獲得了明文密碼，則可以通過任何一台與目标環境連通的主機登入目标環境。當然，我們可以通過其他手段來進行安全加強，例如在密碼傳輸過程中加密，甚至一次一密的傳輸，不過這樣做的代價顯得略高。

安全性上，預分發公鑰方案勝出

1. 便捷性

• 預分發公鑰到目标伺服器

  在使用前需要有分發公鑰的步驟

• 使用使用者名+密碼ssh登入

  無需額外的操作，但需要在ansible主控端上安裝sshpass（很簡單）

便捷性上，使用者名+密碼方案勝出

1. 可維護性

• 預分發公鑰到目标伺服器

  隻要ansible主控端不重新生成密鑰對，目标主機不删除已分發的秘鑰，則無需額外的維護步驟

• 使用使用者名+密碼ssh登入

  考慮到可能的密碼變更，本方案需要額外的維護成本。一旦登入密碼被（環境使用方而非管理方）修改，則原有的憑證失效

可維護性上， 尤其是目标環境達到一定規模之後，預分發公鑰可維護性上的優勢是十分明顯的，預分發公鑰方案勝出

從以上三點出發幾經考慮，我還是選擇了預分發公鑰的方案。

前提是我的工作場景有着對目标環境規範的、完備的、覆寫全生命周期的管理體系，即使是從便捷性考慮，預分發秘鑰無非是在目标環境部署時增加一小段代碼，并不複雜。是以在我們的應用場景中，第二點上預分發秘鑰方案的劣勢并不突出。至于到每個人具體的方案選擇上，還是要根據實際工作環境情況去考量。