症狀：員工已通過 Access，SSH 仍被 Mac 拒絕；CI Runner 則卡在需要互動登入的步驟。

最快判斷：Cloudflare Tunnel 可為遠端 Mac 提供不開放公網 SSH 入站連接埠的接入路徑，但 Tunnel 和 Access 不會取代 Mac 本機帳號、SSH 權限或 CI 憑證治理。本週先分開設計交互式運維與無人值守 CI，再依身份政策、主機授權和斷線恢復演練決定是否上線。

企業 IT 負責人：需要為異地員工劃定遠端 Mac 的 SSH 接入邊界。
平台工程負責人：需要將開發者的交互式連線與 CI 服務帳號分開管理。
安全負責人：需要核對身份政策、本機 SSH 權限、稽核紀錄與撤權責任。

01

Cloudflare Tunnel 遠端 Mac SSH：先釐清各層責任

Tunnel、Access 與 macOS SSH 處理的是不同環節，不能把其中一層的驗證結果當成整條鏈路已安全。Cloudflare 說明 Tunnel 可從執行端建立對外連線，讓服務透過設定的路由被存取；採用此路徑時，不必為 SSH 對公網開放主機入站連接埠。Cloudflare Tunnel 文件

連線路徑可拆成：

開發者或 CI → Cloudflare Access 身份政策 → Tunnel 路由 → macOS SSH 服務 → Mac 本機使用者與授權

各層的工作如下：

  • Access：檢查請求者身份及政策是否允許存取。政策需依組織的身份來源、群組和目標設計，不能只依賴「已登入」這個狀態。Access 政策文件
  • Tunnel：負責將指定主機名稱或路由帶往可達的 SSH 服務。若 Tunnel 執行於另一台設備，那台設備也必須能連到目標 Mac。
  • macOS SSH：Mac 必須啟用遠端登入，並允許預期的本機帳號使用 SSH。Apple 的說明也將遠端登入設定與可登入使用者分開處理。Apple 遠端登入說明
  • 本機帳號：決定登入後可讀取、修改或執行哪些工作。即使 Access 放行，也不會自動將帳號限制為最小權限。

企業遠端 Mac 接入至少有三項常被忽略的邊界：Tunnel 的網路路徑不等於本機授權；身份驗證成功不代表使用者只能操作指定專案；一條可供人員操作的 SSH 連線也不代表 CI 能以相同方式無人值守執行。

02

接入前先分開交互式存取與 CI 身份

部署前先確認需求屬於哪一種認證情境。交互式運維通常由員工身份、裝置上的 SSH 用戶端及本機帳號共同完成；CI 工作則需要可在無人操作時使用、並能由團隊撤銷的服務身份或憑證。兩者不應共用開發者個人私鑰。

常見接入方式不可視為互換方案：

  • 用戶端 cloudflared：適合已管理用戶端、需要透過 SSH 用戶端連線的互動式存取。連線設定需將 SSH 主機名稱交由 cloudflared 處理，並另行指定 Mac 上獲授權的使用者。SSH 用戶端認證與路由文件
  • SSH 基礎設施存取：若需要按目標、使用者等條件細分政策，或需要評估更完整的 SSH 稽核能力，應依官方說明核對其認證流程與功能邊界，而非只加一條一般 Access 政策。SSH 基礎設施存取說明
  • 瀏覽器終端：可供部分互動式管理情境使用，但不應視為通用 CI 用戶端或完整圖形化遠端桌面。先核對瀏覽器終端的適用條件與限制，再決定是否納入工作流程。瀏覽器終端文件

在建立路由前，先指定身份政策負責人、Mac 本機帳號負責人，以及人員離職或憑證外洩時負責撤銷存取的角色。團隊若尚未明確指定撤權責任人，先不要將接入方式擴大到正式環境。

03

第一步：盤點 Mac、帳號與 Tunnel 執行位置

先從目標 Mac 檢查遠端登入設定、可用本機帳號及 SSH 服務狀態，確認哪些帳號必須登入、哪些帳號不應獲得管理權限。接著確認 Tunnel 是部署在目標 Mac 本機，還是部署在另一台可連到該 Mac 的設備；兩種拓撲的服務位址不同，不能直接複製同一組路由設定。

在 Mac 本機運行 cloudflared 時，還要確認它以服務方式啟動時所使用的設定檔與執行上下文。不要假設互動式終端中測試成功，就表示系統服務啟動後也會讀到相同設定。部署前應依照 macOS 服務執行文件核對安裝與服務設定。

盤點結果至少應回答：

  • Tunnel 執行設備能否連到預期 Mac 的 SSH 服務？
  • 路由目標是否指向正確主機與服務，而不是管理設備本身？
  • Mac 是否只允許必要帳號使用遠端登入？
  • 員工離職、服務帳號輪替及緊急撤權分別由誰執行？
04

第二步：建立 Tunnel 路由並確認設定上下文

選定可連到目標 Mac 的 Tunnel 執行位置後，將 SSH 路由指向該 Mac 的 SSH 主機與服務連接埠。若 Tunnel 在目標 Mac 上執行，路由服務位址通常指向該機本機 SSH 服務；若 Tunnel 在另一台設備執行，則應指向該設備可達的 Mac 位址。實際路由格式須按採用的管理方式及官方設定文件核對。

本機管理設定的概念範例如下。主機名稱與服務位置是替換用值，不是可直接套用的組織設定：

ingress:
  - hostname: <SSH_HOSTNAME>
    service: ssh://<MAC_REACHABLE_ADDRESS>:<SSH_PORT>
  - service: http_status:404

套用前確認主機名稱已納入預期的 Access 應用及政策範圍，並檢查路由落點確實是目標 Mac。若設定由 macOS 服務載入，還要在服務執行上下文中確認設定檔可讀、路由仍可用；不要只根據終端工作階段的測試結果判定部署完成。

05

第三步：從用戶端完成首次 SSH 連線

採用用戶端 cloudflared 時，SSH 用戶端設定需包含目標主機、Mac 本機登入使用者，以及將連線導向 cloudflared 的 ProxyCommand。以下是欄位結構示例，主機名稱及帳號應替換為組織實際設定：

Host remote-mac
  HostName <SSH_HOSTNAME>
  User <MAC_LOCAL_USER>
  ProxyCommand cloudflared access ssh --hostname %h

先由一名受控測試使用者執行連線，分別記錄身份政策結果與 Mac 本機登入結果。若 Access 拒絕，檢查身份與政策；若 Access 已放行但 SSH 仍失敗，檢查本機遠端登入、目標路由、使用者名稱和帳號授權。兩層分開排查，比直接放寬 Mac 帳號或 Access 政策更能保留安全邊界。

若使用基礎設施存取或瀏覽器終端，請依其對應文件設定及測試；不同方案的認證流程與稽核能力不能混寫成同一條連線程序。基礎設施應用文件可用來核對該類應用的設定範圍。需要保留登入稽核時，也應先確認可取得哪些欄位，而不是假設所有 SSH 操作內容都會自動記錄；Access 認證紀錄欄位說明可協助核對身份驗證紀錄範圍。

06

CI 驗證必須使用獨立服務身份

不要預設互動式 Access 登入能直接用於無人值守工作，也不要把開發者的個人金鑰複製到 Runner。先以非正式流水線驗證 CI 服務帳號能否按團隊政策完成所需連線，再記錄認證方式、憑證存放位置、負責輪替的人員及撤銷步驟。

驗收時分開判定以下狀態：SSH 可連通、CI Agent 正常執行、建置工作完成、發布簽署成功。某一步通過，不表示後續工作已驗證。若 CI 需要互動式登入、憑證無法撤銷，或服務帳號權限超出任務範圍，應先整改；不應以「SSH 能連線」作為正式啟用的唯一依據。

07

用可勾選清單決定是否上線

依序執行測試，並把結果、責任人及回退方式寫入同一份驗收紀錄。以下項目未完成時，應採限期整改或限制用途，而不是直接放行：

  • [ ] 記錄 Tunnel 執行位置、目標 Mac、SSH 路由及對應的 Access 應用。
  • [ ] 確認 Access 政策只放行預期身份，並分別測試允許與拒絕結果。
  • [ ] 確認 Mac 遠端登入只涵蓋必要帳號，並驗證帳號權限符合工作需求。
  • [ ] 以非正式 CI 工作測試服務身份；記錄憑證位置、輪替責任人與撤銷程序。
  • [ ] 撤銷測試身份後再次連線，確認存取被拒絕並保留可查的驗證紀錄。
  • [ ] 模擬 Tunnel 斷線及 Mac 重啟，確認告警、人工處置路徑與責任交接。
  • [ ] 修改測試帳號權限後重做 SSH 驗證，確認權限變更確實反映在目標主機。
  • [ ] 記錄回退動作；不以未實測的可用率或恢復時間作為上線承諾。

結果可分為四種：通過後按已驗證範圍上線；限期整改後重驗；僅允許交互式存取、暫不開放 CI；或在身份、主機授權及撤權流程無法驗證時不准入。若團隊仍在評估託管 Mac 的採購與接入條件，可先參考 遠端 Mac 方案資訊，並依團隊所在地及網路要求核對實際可選項目。

08

常見問題

Access 通過後是否代表 Mac 管理權限已受控？

不代表。Access 檢查的是其政策涵蓋的身份與存取條件；Mac 上可用的帳號、SSH 登入授權及管理權限仍須另行設定。驗收時至少分別記錄 Access 是否放行、SSH 是否接受該本機使用者，以及登入後能否執行超出工作範圍的操作。

同一政策能否限制員工連到不同 Mac？

應依目標主機與組織的身份分組設計政策，並逐一驗證允許和拒絕情境。若需求涉及更細緻的目標或登入使用者限制，需評估基礎設施存取方案能否提供所需控制；即使 Access 層已分流，也不能省略 Mac 本機帳號及權限檢查。

CI 能否沿用工程師的 SSH 設定？

不建議。工程師的設定通常依賴個人身份或互動式認證，離職或權限變動時也容易留下未更新的憑證。CI 應使用專屬服務身份，並由團隊記錄憑證保管、輪替和撤銷方式；在非正式流水線確認無人值守流程可行後，再評估正式用途。

SSH 成功是否表示 iOS 建置和簽署已驗收？

不是。SSH 成功只證明當下的連線與登入路徑可用，不代表 CI Agent、建置步驟或發布簽署流程均已通過。請將連通、Agent 執行、建置完成及簽署結果分開記錄，避免把網路接入測試誤當成整條 CI 流程的驗收。

Cloudflare Tunnel 能解決遠端 Mac 的網路接入路徑，卻不會自行處理 Mac 本機權限、CI 憑證或圖形化控制需求。相較之下，自行維護主機需要承擔硬體採購與折舊、更新維護，以及故障恢復安排；單靠 SSH 也無法取代團隊需要的圖形化操作。若需求是短期測試環境或彈性增加 Mac 容量，租用遠端 Mac 可減少自行備置實機的工作；若屬長期穩定重負載或必須使用特定實體介面，則應先比較自購與租用條件。NodeMini 的方案與接入資訊可由遠端 Mac 方案頁面核對，再確認是否符合團隊的 SSH、CI 與運維要求。