GitHub 官方 SSH 連線測試使用 ssh -T git@github.com 這個指令；先在實際執行 Git 的裝置上測試，再處理該裝置的憑據，才不會把 iPad 的金鑰誤當成遠端 Mac 的金鑰。GitHub 官方測試步驟說明了測試方式：本週先定位命令執行位置，再核對金鑰、帳號與倉庫權限。不要把私鑰隨意複製到 iPad、臨時電腦或無法確認清理方式的共享主機。

適合在旅途中透過遠端 Mac 開發、遇到 GitHub SSH 認證失敗的獨立開發者。
需要在 iPad、輕薄本與遠端 Mac 之間切換工作的數位遊民。
使用臨時或共享環境，並在意私鑰留存與撤銷方式的遠端顧問。

先定位 Git 命令，再判斷 GitHub SSH 認證失敗在哪一層

同一個專案可能在不同裝置開啟，但每台裝置的檔案、登入使用者、SSH 設定與 agent 狀態並不相同。你在 iPad 上開啟遠端桌面後，若於遠端 Mac 的終端機執行 git pull，認證發生在遠端 Mac；若在 iPad 本機終端機執行，使用的則是 iPad 所在環境的設定。兩者不是同一份憑據。

先在出錯的終端機查看主機名稱與目前使用者，再核對該終端機所在路徑的 Git 遠端位址：

  • hostname：辨認命令所在主機。
  • whoami：辨認目前使用者。
  • git remote -v：確認倉庫實際指向的遠端位址。

記下這些結果，再排查同一台裝置。若你是透過 Apple 遠端登入連線至 Mac，這項功能可用 SSH 或 SFTP 存取 Mac；它只描述連線方式，不能證明主機的帳號隔離或金鑰管理符合你的專案要求。Apple 的 Mac 遠端登入說明

這個區分也能避免混淆兩種不同憑據：你登入遠端 Mac 的憑據，與 GitHub 用來認證 Git 操作的 SSH 金鑰。遠端桌面能連上，不代表 GitHub 也已授權；反過來，GitHub 金鑰可用，也不代表你能登入那台 Mac。

從錯誤表現分辨金鑰、帳號與倉庫權限

GitHub SSH 認證失敗，不一定是網路問題。先執行官方測試指令，再依結果縮小範圍：

  • 連線未完成或出現連線錯誤：先檢查目前網路是否能連到 GitHub，以及 SSH 用戶端是否能與服務端完成連線。不要只因旅途中網路不穩，就假設帳號或公鑰設定必然錯誤。可對照GitHub SSH 故障排查指引檢查錯誤類型。
  • 出現 Permission denied (publickey) 等金鑰相關錯誤：檢查目前主機是否持有預期的私鑰、SSH 設定是否指向正確路徑，以及 agent 是否載入該身分。接著確認對應公鑰已加入你預期使用的 GitHub 帳戶。
  • 測試表示已認證，但讀取或寫入倉庫失敗：認證成功不等於有權存取指定倉庫。核對遠端位址、帳戶身分、組織授權與倉庫權限；GitHub 也將倉庫存取問題與 SSH 金鑰認證分開說明。倉庫複製錯誤與權限檢查

GitHub 的 SSH 認證使用一組相互對應的公鑰與私鑰：公開的一端登記到帳戶，私鑰則留在需要執行 Git 操作且你信任的環境中。GitHub 對 SSH 認證的說明因此，不要把私鑰內容貼到客服訊息、終端機截圖或同步資料夾；排查時檢查檔案是否存在與權限設定即可，不需要公開私鑰。

遠端 Mac 找不到金鑰時，先檢查再新增

不要一遇到認證錯誤就生成新金鑰。先在實際執行 Git 的遠端 Mac 上檢查目前使用者的 SSH 設定與金鑰檔案；GitHub 提供了檢查現有 SSH 金鑰的步驟。只確認檔案與對應公鑰，不要用 cat 顯示私鑰內容，也不要把它傳到旅途中的其他裝置。

若已找到金鑰，接著核對 SSH 設定是否指向正確檔案，並查看目前工作階段的 agent 是否載入預期身分。可用 ssh-add -l 檢查 agent 列出的身分；若沒有預期項目，先依官方流程處理 agent，再測試 GitHub 認證。ssh -vT git@github.com 可協助觀察用戶端實際嘗試的認證流程，但除非需要提供支援，不要公開完整輸出，因為內容可能包含主機名稱、使用者名稱或路徑等環境資訊。

只有在確認沒有可用金鑰，且你能妥善保管新私鑰時，才考慮建立專用金鑰並將公鑰加入正確帳戶。GitHub 的建立 SSH 金鑰並加入 ssh-agent 說明列出生成與載入流程；新增公鑰時，按官方新增 SSH 金鑰步驟登記到預期的帳戶。不要覆蓋已有工作憑據，也不要把「重新生成」當成倉庫權限錯誤的通用解法。

口令反覆出現時，檢查 agent 與鑰匙圈狀態

SSH 金鑰口令用來保護私鑰，不是 GitHub 帳戶密碼，也不是遠端 Mac 的登入口令。若每次連線或工作階段重新建立後都被要求輸入，可能是 agent 未載入預期金鑰、登入工作階段變更，或 macOS 鑰匙圈設定未按預期工作。不要為了少輸入一次，就移除私鑰保護。

先確認提示視窗所要求的究竟是哪一種口令，再查看 agent 是否持有相應身分。接著依 GitHub 的macOS ssh-agent 與鑰匙圈設定說明核對目前設定。調整後，結束並重新建立遠端工作階段，再執行 SSH 測試與實際 Git 操作；若提示仍重現，就把「每次重新連線都要輸入口令」視為尚未解決，而不是假設狀態已永久保存。

先處理憑據風險，再決定是否在共享主機工作

金鑰放在哪裡，決定了誰可能接觸它，也決定了出問題後要撤銷哪一份憑據。自有且由你管理的遠端 Mac，與借用電腦、臨時主機或多人共用環境，風險邊界不同。不要把 SSH agent 轉送或遠端桌面連線視為沒有風險的捷徑；先確認主機使用者、存取範圍與清理責任。

若懷疑私鑰曾被未授權的人取得，優先從 GitHub 帳戶撤銷對應公鑰，再建立替代憑據。GitHub 說明了如何檢查並刪除帳戶中的 SSH 金鑰。撤銷後，再檢查是否有私鑰副本留在同步目錄、臨時裝置或舊工作環境。只刪除主機上的檔案，不等於已撤銷 GitHub 帳戶中的授權。

常見疑問：把旅途中的故障縮小到可處理範圍

金鑰錯誤、帳號錯誤和網路問題要怎麼分辨？
先在 Git 命令實際執行的主機執行 ssh -T git@github.com。若連線未完成，先看網路與 SSH 連線錯誤；若公鑰不被接受，檢查該主機上的金鑰與帳戶登記；若已認證但無法操作目標倉庫，轉查帳號與倉庫權限。這樣能避免在錯誤層級反覆改設定。

遠端 Mac 執行 Git 時，私鑰應該放在哪裡？
如果 Git 命令由遠端 Mac 執行，應由那個受信任、可管理的執行環境提供 GitHub 憑據。iPad 本機金鑰不會自動成為遠端 Mac 的金鑰。若無法確認主機的使用者隔離、存取方式或清理程序，就不要把個人私鑰放上去；改採符合帳戶與組織規範的替代認證方式，或暫停操作。

為什麼 macOS 重啟或遠端工作階段中斷後又要輸入口令？
工作階段重新建立時，ssh-agent 可能沒有載入原有金鑰；鑰匙圈設定也可能影響口令提示。先辨認提示的是金鑰口令、GitHub 帳戶認證，還是 Mac 登入憑據，再檢查 agent 與鑰匙圈設定。調整後須在重新連線的工作階段重測，不應承諾中斷後一定保留狀態。

臨時或共享遠端 Mac 上的金鑰如何撤銷？
到 GitHub 帳戶的 SSH 金鑰管理頁，辨認並移除曾在該主機使用的公鑰；若無法排除私鑰外洩，就撤銷後另建憑據。然後檢查可能留有私鑰的同步目錄與裝置，並重新測試舊金鑰是否已無法通過認證。只刪除本機檔案不足以完成撤銷。

復工前用真實倉庫完成驗收

修好 SSH 連線後，不要只以測試指令顯示已認證就結案。選擇你確實獲授權的倉庫，按專案工作需求驗證讀取與寫入；若不需要寫入，不要為了測試而推送無關變更。把以下清單作為復工檢查，並留存可供你日後撤銷與重建環境的紀錄：

  • [ ] 記下 Git 命令實際執行的主機名稱與目前使用者。
  • [ ] 確認 git remote -v 指向正確倉庫，並確認使用的是預期 GitHub 帳戶。
  • [ ] 確認該環境使用的 SSH 金鑰檔案位置；只檢查公鑰與路徑，不複製或展示私鑰。
  • [ ] 確認 agent 是否載入正確身分，並在遠端工作階段重新建立後再次測試。
  • [ ] 用獲授權的倉庫驗證實際需要的讀取或寫入操作。
  • [ ] 記下疑似外洩時要移除哪一把 GitHub 公鑰，以及到哪裡執行撤銷。
  • [ ] 若主機屬於共享或臨時環境，先確認使用者隔離、存取邊界與離開後的清理方式；無法確認就不要留存個人私鑰。

若你的開發工作需要持續使用 macOS，但旅途中帶著 MacBook 會增加行李負擔，或自有裝置遺失時難以立即恢復環境，可以評估由 VMSPIN 提供的遠端 Mac 方案。它適合需要遠端 macOS 工作環境的人，但不會自動解決 GitHub 金鑰保管或倉庫授權；先核實主機存取與憑據管理邊界，再判斷是否適合承載你的專案。你可先查看 VMSPIN 遠端 Mac 服務資訊與方案說明，確認環境適用性後再作決定。