痛點拆解：抗釣魚的代價不是多買幾支金鑰
痛點 1：把 FIDO2-SK 當成「更強 ed25519」。失敗樣態會變成 PIN 鎖、觸控逾時與 USB 供電抖動，難以用單一錯誤碼解讀。
痛點 2：人類與 CI 共用 authorized_keys。夜間矩陣作業會在人員休息時集中失敗，重試亦可能觸發 MaxAuthTries。
痛點 3：忽略主機身分。FIDO2 強化用戶端，仍需 known_hosts 固定指紋。
痛點 4：傳輸與認證混談。大量併發上傳時請先檢視 併發 SFTP，避免誤判為金鑰故障。
痛點 5：把 CA 與 OIDC 視為互斥。實務上常並存：CA 管到機登入、OIDC 管存放庫到流水線；矩陣用於劃清邊界。
痛點 6：政策與值勤表脫鉤。若強制觸控卻無人可供驗證，夜間發佈窗只會被迫改走弱替代路徑，反而放大風險敞口。
威脅模型與指標：把安全變成可觀測事件
至少記錄成功／失敗原因、主機金鑰校驗、併發連線峰值與 OIDC 發放失敗率；人類路徑看 PIN／觸控耗時，自動化路徑看憑證 TTL 與 audience 拒絕率，並與 OIDC 部署矩陣 的 claims 變更稽核連動。
遠端 Mac 常同時承載編譯、簽章與大量檔案傳輸；認證面與傳輸面應分開擴容，避免把互動式驗證延遲轉嫁為 SFTP 吞吐崩潰。
量化基線：用數字結束「感覺更安全」
互動式 ssh 啟用觸控常見額外延遲約 2–8 秒；CI 憑證建議在 TTL 剩餘低於約 20% 時刷新；OIDC 發放失敗若高於每千次建置約 3 次，應優先檢 audience 與出口 IP；單一連線上傳接近 200 Mbps 時應為傳輸工作另外限速，保障維運視窗。
決策矩陣：FIDO2-SK、SSH CA、OIDC、混合
| 路徑 | 最佳呼叫端 | 主要收益 | 主要成本 |
|---|---|---|---|
FIDO2 *-sk | 工程師工作站 | 抗釣魚與硬體隔離 | 觸控／PIN 與 CI 衝突 |
| SSH CA | 平台自動化 | 短 TTL、可撤銷序號 | 簽署金鑰維運 |
| OIDC | 託管 Runner | 無硬體、可稽核 | 依賴 IdP 與 audience |
| 混合 | 中大型組織 | 體驗與安全折衷 | 需嚴格 principal 與帳號隔離 |
實作步驟與命令錨點
# 人類路徑（僅示意，依企業政策調整）
# ssh-keygen -t ed25519-sk -O verify-required -f ~/.ssh/id_ed25519_sk
# 檢視 sshd 驗證方法
# sshd -T | egrep 'passwordauthentication|pubkeyauthentication|authenticationmethods'
# CI：優先 OIDC 或短期憑證，而非長效共用 PEM
步驟 1：標記人類／自動化／委外呼叫端。
步驟 2：以 Match 分離 CI，避免套用 verify-required。
步驟 3：自動化選 CA 或 OIDC 並設 TTL 儀表板。
步驟 4：Runner 使用秘密庫中的 known_hosts。
步驟 5：調校 SFTP 併發與 keepalive。
步驟 6：升級 OpenSSH 或韌體後做小樣本迴歸。
閱讀順序與 CTA
FAQ 與為何評估 SFTPMAC 託管遠端 Mac
FIDO2 能否取代 SSH CA？
兩者解題不同：CA 處理短期身分與撤銷效率；FIDO2 處理人類抗匯出。應並存並於 authorized 層物理隔離。
OIDC 會讓存放庫變根權限嗎？
若權限過寬會；請採最小權限並拆分上傳／編譯／發佈帳號。
觸控失敗先查什麼？
USB 供電與集線器，其次 sshd 是否因重試觸發限次，最後是否人機共用帳號。
總結：FIDO2-SK 把「人在場」寫進最短路徑，抗釣魚強但不解 CI 無頭、主機身分與併發傳輸；應把 FIDO2 留給工程師、CA／OIDC 留給自動化，並以 known_hosts 與限次兜住公網現實。
限制：自建池需在韌體、USB、sshd、流水線範本間持續對齊，間歇性觸控失敗常造成跨夜排障。
對照收束：SFTPMAC 託管遠端 Mac 將 Apple 生態相容、穩定在線與傳輸治理產品化，團隊可專注建置與發佈，減少「CI 等人摸金鑰」的迭代耗損；認證與傳輸一併託管時，租賃遠端 Mac 通常比分散自管節點更易獲得穩定交付體驗。
把人類 FIDO2 路徑與自動化 CA／OIDC 路徑拆 principal，託管環境較易做到配額、稽核與迴歸樣本一致。