科技 · 實用指南
SSH 顯示「Permission denied (publickey)」？複製新金鑰前先證明實際送出的指紋
先列出有效目標，擷取客戶端實際送出的金鑰指紋，再對應到目標帳號並檢查伺服器拒絕證據；不要先改權限或政策。
「Permission denied (publickey)」表示連線已進入使用者認證，但伺服器未替要求的帳號接受可用公鑰路徑。它不能指出是選錯金鑰、金鑰屬於別的帳號，或伺服器政策拒絕。
建立四欄證據：有效目標、實際送出的指紋、帳號授權對應與伺服器拒絕記錄。第一個斷開的關聯就是最小修復位置。
固定確切目標與呼叫端
保存失敗命令、別名、遠端使用者、連接埠、跳板路徑與執行環境。以相同目的地執行 ssh -G，記錄有效設定；能在失敗的 IDE、服務或容器內重現更佳。
不要用本機使用者名稱或 DNS 猜遠端帳號。公鑰授權綁定遠端帳號，錯誤別名或 User 指令會讓有效金鑰看似失效。
只記錄真正送出的金鑰
執行 ssh -vvv 並保存認證段，逐條記錄「Offering public key」來源與指紋。身分檔遺失和已送出但被拒是不同分支。
若預期指紋沒出現，檢查有效 IdentityFile、agent socket 與呼叫端 HOME。以 -i 和 IdentitiesOnly=yes 做窄範圍測試。
把指紋對應到目標帳號
從公鑰或核准 agent 清單計算 SHA256 指紋，絕不暴露私鑰。與遠端帳號或託管平台帳號登記的金鑰精確比對。
關聯未知前不要重複複製金鑰；新增金鑰可能擴大授權，卻不改變原呼叫環境。
確認送出仍被拒才查伺服器
正確指紋已送出仍被拒時，在獲准伺服器查看認證日誌和實際授權來源。檢查帳號、AuthorizedKeysFile 或目錄對應、擁有者、權限、憑證、Match 與演算法政策。
不要遞迴 chmod 或降低認證要求。只修正已證明的帳號與路徑問題，再從原呼叫端測試。
以前後證據閉環
從失敗環境重跑 ssh -G 與 ssh -vvv，確認目標、帳號和預期指紋一致，且無需降級即可成功。
保存脫敏帳本、時間與呼叫端身分，讓日後 IDE、agent、別名或帳號變更能直接比較。
