「權限不對」,其實從來就不是權限的問題
不管怎麼重寫 Windows 檔案的 ACL,OpenSSH 每次都拒絕接受這把私鑰,說它不安全——因為它實際上在檢查的東西,根本跟 ACL 無關。
This article is also available in English: English version——內容相同,僅語言不同。
把一條 SSH 反向通道設定成 Windows 背景服務執行,OpenSSH 每次都以「權限不對/太開放」的錯誤, 拒絕使用那把私鑰——這句話字面上聽起來,就是直接在講檔案 ACL 的問題。 一輪又一輪收緊權限,完全沒有任何效果,因為真正被檢查的那個不變條件, 根本就不是什麼權限位元。
看起來理所當然的修法,重複做了好幾次,完全沒用
整套設定是:一條 SSH 反向通道,用一個服務包裝工具, 設定成 Windows 背景服務執行(這樣開機就會自動啟動,不需要互動式登入), 用一把私鑰檔案做身分驗證。每次服務啟動,OpenSSH 都拒絕使用那把金鑰, 錯誤大致是「UNPROTECTED PRIVATE KEY FILE」/權限太開放—— 這句話讀起來,就是明確在指示你去修檔案的存取控制清單(ACL)。 而這正是反覆被嘗試的做法:把繼承來的權限從金鑰檔案上拿掉, 只明確授予服務所使用的那個帳號最小限度的存取權, 再直接檢查產生出來的 ACL,確認它看起來完全符合教科書標準。 每一輪做出來的 ACL,就任何一般對 Windows 檔案權限的理解來說, 都應該足以通過任何合理的安全檢查。但錯誤完全沒有任何改變。
Unlock this article to keep reading, or subscribe for unlimited access to everything. See Pricing for details.