我發現文檔中的以下要求爲Net::OpenSSH:爲什麼公鑰驗證是自動腳本的首選?
注意,在自動腳本中使用密碼 認證 一個非常糟糕的主意。如果可能,您應該使用公鑰認證 代替。
在自動腳本中使用密碼驗證有什麼缺陷?
我發現文檔中的以下要求爲Net::OpenSSH:爲什麼公鑰驗證是自動腳本的首選?
注意,在自動腳本中使用密碼 認證 一個非常糟糕的主意。如果可能,您應該使用公鑰認證 代替。
在自動腳本中使用密碼驗證有什麼缺陷?
密碼是容易猜出比私鑰/蠻力(除非您正在運行Debian;)
假設你有一個用戶帳戶它運行120個不同的自動腳本。如果您將密碼硬編碼到每個密碼中,則您現在有120個位置可以對其進行更改。
如果您將密碼放入配置文件並且所有120個腳本遲早會從文件中讀取它,則有人會意外地使該文件具有世界可讀性。當私鑰不是600時,ssh將不起作用。
有人可以決定更改用戶的密碼,而不必考慮它在某些腳本中被硬編碼的可能性。在更改私鑰之前,您更有可能停下來思考。
當私鑰不是600時'ssh將不工作。 - 使用密碼驗證,你可以檢查你的腳本,如果配置文件是600. '有人可以決定更改用戶的密碼,考慮它在某些腳本中被硬編碼的可能性。「 - 有人可能意外地覆蓋了'.ssh/authorized_keys' – codeholic 2010-03-25 18:50:57
您不能集中強制所有人編寫腳本來檢查權限,但是您可以禁用服務器上的密碼驗證然後你知道每一個訪問它的腳本都使用公鑰/私鑰對,並且沒有在世界上可讀的文件中將密碼設置爲g0d。安全的一部分是關於不相信任何人,包括你自己。絕對是同事。 – 2010-03-25 18:59:13
好的,很明顯。但我想知道,除了您提到的人爲因素外,是否還有其他優勢。技術優勢,如果你願意的話。 – codeholic 2010-03-25 19:04:16
對於任何遠程資源,公鑰驗證始終應該是首選。從統計學角度來看,猜測挑戰反應並阻止MITM攻擊是不可能的。雖然這並不排除攻擊者很有可能是極其幸運。
如果攻擊者可以讀取遠程系統上的文件,則密碼或私鑰必須是純文本,並且可以讀取。不對稱密碼學不是解決所有問題的魔術棒。
文檔中出現此警告的一種可能性是,如果您使用密碼並且腳本未檢查sshd的公鑰,則MITM攻擊可能會獲得明文密碼。您應該通過對公鑰進行硬編碼來檢查遠程服務器身份驗證。 cli上的ssh命令會自動執行此操作,並在服務器密鑰更改時發出警告。如果您沒有檢查遠程服務器的身份驗證憑據並且正在使用公鑰身份驗證,那麼攻擊者只能使用MITM會話,因爲攻擊者無法獲取客戶端的私鑰以重新授權。
我打算假設大多數時候自動化腳本會以容易被盜的方式存儲密碼。 – 2010-03-25 18:28:20
@Chris Marisic:私鑰也可能被盜。 – codeholic 2010-03-25 18:33:09
但私鑰本身是用密碼加密的。這不是萬無一失的,但至少還有一層。 – guns 2010-03-25 23:19:57