這篇整理管理員登入伺服器作業系統的通道怎麼設計，內容與雲端廠商無關，適用於雲端 VM、地端主機與 VPS。適用的前提是服務跑在自己管理的主機上、而且有人要登入那台主機的作業系統；跑在不提供主機登入的平台（PaaS、serverless）上，就沒有這條通道要設計。機制以 SSH 說明，RDP 的差異在〈對外開放管理 port 的實際風險〉與〈主機登入驗證的做法〉另外交代。GCP 上的機制見 GCP VM 的 SSH 與 RDP 管理通道：從預設的全開規則改走 IAP TCP forwarding，逐步的指令見 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄。

管理通道的三層：網路可達性、通道授權、主機登入驗證

管理通道指管理員從自己的電腦登入伺服器作業系統的那條路徑。一次 SSH 登入依序經過三層檢查，每一層的做法可以分開選，但有些做法同時落在兩層：

  • 網路可達性：管理員電腦送出的封包是否到達得了伺服器上 sshd（SSH 的伺服器端程式）監聽的 port。防火牆規則、伺服器是否持有公開 IP、中間是否經過代理，決定的都是這一層。
  • 通道授權：在封包抵達 sshd 之前，是否有一個元件先確認「這個人可以使用這條通道」，以及它憑什麼確認——來源 IP、VPN 憑證、跳板機上的 SSH 金鑰，或一個身分提供者（identity provider，IdP）上的帳號。
  • 主機登入驗證：封包抵達 sshd 之後，sshd 用什麼判斷這個連線可以登入哪個帳號——authorized_keys 裡的靜態公鑰、由中央服務動態提供的公鑰，或 SSH CA 簽發的短期 SSH 憑證（SSH certificate）。

防火牆對 0.0.0.0/0（CIDR 表示法裡的「所有 IPv4 位址」）開 22 port 的狀態，在這個模型裡是網路可達性全開、通道授權不存在、只剩主機登入驗證一層在擋。收斂管理通道的做法，多數是替網路可達性與通道授權換上更嚴格的做法；主機登入驗證另有它自己的換法，從要逐台刪除的靜態金鑰，換成跟著帳號收回、或會自動到期的金鑰。

每一層擋下的攻擊者，是手上的存取憑證與所在位置過得了前面幾層、過不了這一層的人。網路可達性擋的是只能從網際網路送封包、還沒有任何存取憑證的攻擊者，例如掃描程式與 sshd 漏洞的利用程式；通道授權擋的是已經能把封包送到通道入口、卻沒有通道身分的人，例如私鑰從筆電外洩、但沒有組織 IdP 帳號的人；主機登入驗證擋的是持有通道權限、卻不該登入某台主機或某個帳號的成員，例如開發者登入他不負責的資料庫主機、或取得他不該有的 sudo。同一個做法可能同時改變兩層（來源 IP 白名單、跳板機、VPN、身分感知代理都兼任通道授權），還有少數做法把三層一起換掉（SSM Session Manager 的預設模式、Tailscale SSH，見〈網路可達性的做法〉），所以評估一個做法時要逐層問它改了哪一層。只加強其中一層時，有能力通過那一層的攻擊者（例如持有 IdP 帳號、卻不該碰這台主機的成員）遇到的另外兩層仍是原本的設定；各層要彼此獨立，這個原則叫縱深防禦（defense in depth）。

對外開放管理 port 的實際風險

管理 port 對整個網際網路開放之後，主機的認證紀錄很快就會出現來自陌生 IP 的失敗登入，開一台測試主機查一次紀錄就看得到。紀錄的位置依發行版不同：Debian 與 Ubuntu 是 journalctl -u ssh 或 /var/log/auth.log，RHEL 系是 journalctl -u sshd 或 /var/log/secure。這些嘗試要成功，取決於主機登入驗證那一層的設定；而只剩那一層在擋時，風險集中在四個地方：

  • sshd 本身的漏洞：2024 年的 regreSSHion（CVE-2024-6387）讓未經認證的連線有機會在 OpenSSH 伺服器上執行程式碼。這類漏洞發生在認證之前，金鑰設定得再嚴格也擋不住；能降低這類風險的是修補速度（縮短暴露期）與收窄網路可達性（減少能把封包送到 sshd 的來源）。
  • 密碼登入：多數雲端廠商的官方 Linux 映像檔預設關閉 SSH 密碼登入、只接受金鑰，單純猜密碼在沒改過設定的主機上不會成功。不少 VPS 商在開機時寄出 root 密碼、或提供「用密碼建立主機」的選項，這類主機的密碼登入一開始就是開著的，要自己關掉。有人為了方便打開 PasswordAuthentication yes、或建了弱密碼的本機帳號，這項預設也會失效，而這類改動發生在主機內部，防火牆看不到。
  • 金鑰的生命週期：私鑰從筆電、CI 或共用資料夾外洩之後，持有者從任何地方都能登入；成員離職時沒從 authorized_keys 移除的公鑰持續有效。組織處理離職時停用的是公司帳號（郵件、IdP），這個動作不會碰到任何一台主機上的 authorized_keys；主機的登入紀錄記的是金鑰指紋而不是人名，那把公鑰之後被拿來登入，紀錄上也對不到是誰。靜態公鑰沒有到期時間，所以「誰還拿得到這台主機」只能靠人工盤點查出來，離職流程要把主機登入層列進去，撤銷清單的寫法見職務交接與存取撤銷設計的〈離職或轉調的存取撤銷清單〉。
  • RDP：Windows 的遠端桌面預設接受帳號密碼，暴力猜測對它的成功率比對只收金鑰的 SSH 高，所以 3389 對外開放的被入侵機率高於 22。RDP 在主機登入驗證那一層的對應是 Windows 帳號，其餘兩層的做法與 SSH 相同。

同一個內部網段裡的主機之間如果所有 port 互通，一台主機被攻破後，攻擊者從那台機器可以直接連到其他主機的資料庫 port 與管理 port，這種擴散方式叫橫向移動（lateral movement）。收斂對外的管理 port 時，內部網段之間的規則要一起盤點，最小開放的設計見網路地基 — VPC、subnet 分層與 security group 設計的〈security group 設計：最小開放〉一節。

更換 SSH port 與 fail2ban 改變的範圍

更換 SSH port 與安裝 fail2ban 常被當成上面這些風險的對策，而它們都不改變「sshd 對全網可達、只靠主機登入驗證在擋」的狀態。更換 port 之後，sshd 仍然對整個網際網路可達，掃描程式找的是開著的 port，不是 22 這個數字。fail2ban 在同一個來源失敗多次之後才封鎖它，所以每個來源的第一次嘗試仍然送得到 sshd；它擋得住重複猜測，擋不住第一次就成功的攻擊（sshd 漏洞的利用、外洩的私鑰）。兩者減少的是認證紀錄裡的雜訊。

網路可達性的做法：管理 port 對誰開放

伺服器是否仍需接受入站連線，把網路可達性的做法分成兩類；這一層的目標是讓 sshd 只對經過通道授權的來源可見。

仍然接受入站、但縮小來源的做法有四種：

  • 來源 IP 白名單：防火牆只放行公司對外的固定 IP。設定成本最低；代價是遠端工作與 IP 變動時要一直改規則，而且公司網路裡任何一台被入侵的電腦都在白名單內。它同時兼任通道授權，判斷身分的依據是 IP。
  • 跳板機（bastion host，其他中文資料常寫作「堡壘主機」）：一台放在公開網段、只用來轉接 SSH 的主機，其他主機只接受來自它的連線。暴露面從每台主機收斂成一台，但那一台仍然對外開著管理 port，要修補、要監控，它的 sshd 漏洞就是整個環境的入口。它同時兼任通道授權，判斷依據是跳板機上的 SSH 金鑰，或跳板機信任的 SSH CA 所簽的憑證。好處是與廠商無關、可以集中錄製操作紀錄。主機只有一台時，跳板機本身就多出一台對外開著 22 port 的主機，暴露面沒有縮小。
  • 從代理位址段連入的身分感知代理（identity-aware proxy）：由廠商提供或自己架設的代理服務在網際網路上接收連線，向 IdP 驗過身分之後，才從代理服務自己的固定位址段連到主機的內部 IP。防火牆只放行那段代理位址，主機本身不需要公開 IP。它同時承擔通道授權。GCP 的 IAP TCP forwarding、AWS 的 EC2 Instance Connect Endpoint 屬於這一類；它是零信任（zero trust）原則在存取入口上的一種實作。身分感知代理也可以改由主機上的代理程式反向連線送進主機，那種送達方式歸在下面的「主機不接受任何入站連線」。
  • VPN：讓管理員的電腦加入內部網路，再用內部 IP 連主機，主機接受的入站只來自 VPN 範圍內的位址。它解決的範圍比管理通道大（資料庫用戶端、內部管理介面都能用），而連上之後通常整個網段都可達，要另外用防火牆規則限縮。VPN 閘道的形態決定它本身的暴露面：SSL VPN 與 IPsec 設備在網際網路上監聽、在認證之前就處理封包，2023 到 2024 年被大規模利用的認證前漏洞集中在這類設備上，它的修補與 sshd 同等重要；WireGuard 不回應沒有通過金鑰驗證的封包，掃描程式看不到它在監聽。Tailscale 這類 mesh VPN 讓每台裝置彼此直連、組成一個私有網路（Tailscale 稱為 tailnet），sshd 只監聽 tailnet 介面的位址，裝置透過 NAT traversal 建立連線、不必對外開入站 port；tailnet 裡的裝置預設彼此互通，收窄要靠 Tailscale 的 ACL。mesh VPN 的登入多半接組織的 IdP，所以它的通道授權依據是 IdP 帳號。Tailscale 另有 Tailscale SSH 模式，由 Tailscale 依 tailnet 的 ACL 決定能登入哪個帳號，取代 sshd 的金鑰驗證，主機登入驗證那一層跟著換掉。Tailscale 依賴它營運的協調伺服器，不想依賴第三方時改用自建的 WireGuard，或接得上 OIDC IdP 的自建協調伺服器（Headscale、NetBird）。連上之後的可達範圍怎麼收窄、哪些限制要放在被入侵的一端改不到的位置，見兩個網路之間的連線安全的〈VPN 提供的保證與邊界模型〉；Tailscale 與自建 WireGuard 的取捨見 Tailscale 深入：tailnet、MagicDNS、直連與 DERP 中繼的〈取捨與邊界〉。

主機不接受任何入站連線的做法是代理程式（agent）反向連線，一種 Outbound Tunnel：主機上常駐一個代理程式，由它主動往外連到管理服務並維持一條連線，管理員的工作階段經由那條連線送進來，防火牆不必為管理用途開任何入站 port。AWS 的 SSM Session Manager 是這一類的代表；Cloudflare Access 搭配主機上的 cloudflared、Teleport 的節點以反向通道連到 proxy，在網路可達性上也屬於這一類，同時它們也承擔通道授權。Tailscale 的連線方向與 outbound tunnel 相同，但 sshd 仍然接受 tailnet 介面的入站，本篇把它歸在 VPN。這一類的前提是代理程式持續在主機上執行，而且主機有連到管理服務端點的出站路徑。

代理程式反向連線的工作階段不一定經過 sshd。SSM Session Manager 預設由代理程式直接在主機上開 shell，決定能登入成哪個系統帳號、是否能用 sudo 的是 AWS 端的權限設定與代理程式的設定，主機登入驗證那一層因此跟著換掉；只有改用經由 Session Manager 轉送 SSH 的模式時，sshd 與金鑰才仍然在路徑上。Teleport 的節點用它自己內建的 SSH 伺服器與 Teleport 簽發的憑證，同樣不經過系統的 sshd。採用前要查清楚該服務的工作階段是直接開 shell、走自己的 SSH 伺服器，還是轉送到 sshd，再決定主機登入驗證那一層要設計什麼。

通道授權的做法：判斷連線使用者身分的依據

比較通道授權的判斷依據時看四件事：分不分辨得出個人、判斷依據能不能被複製給別人、收回之後多久生效、留不留得下「是誰」的紀錄。判斷依據與網路可達性的做法不是一對一：VPN 可以用 PKI 簽發的憑證，也可以接 IdP 帳號（mesh VPN、多數商用 VPN 的 SAML 登入），接 IdP 時屬性看 IdP 帳號那一列。

判斷依據分辨個人能否被複製收回生效「是誰」的紀錄
來源 IP分辨不出同一網路的任何人都通過改防火牆規則之後立即生效，但收回的是整個網路只有 IP，對不到人
VPN 憑證每人一張時分辨得出憑證檔能複製，綁在硬體 token 上時不能PKI 型 VPN 靠伺服器維護的憑證撤銷清單；WireGuard 從伺服器設定刪掉那個人的公鑰VPN 伺服器的連線紀錄
跳板機上的 SSH 金鑰每人一把時分辨得出私鑰檔能複製；存在硬體安全金鑰裡的 -sk 金鑰不能要到跳板機的 authorized_keys 刪除跳板機紀錄裡的金鑰指紋
IdP 帳號分辨得出登入那一刻取決於多因素驗證；登入後留在本機的 token 能被複製，取決於代理的 session 長度與裝置綁定IdP 停用之後，代理自己簽發的 session 或憑證到期才失效；收回延遲的上限是代理端設定的 session 長度每一次開通道都記錄是哪個帳號

跳板機與目的主機接受同一把金鑰時，一把私鑰外洩就同時通過通道授權與主機登入驗證，兩層退化成一層。SSH 金鑰那一列的硬體金鑰（OpenSSH 8.2 起支援 FIDO2 的 ed25519-sk）讓私鑰離不開那支實體金鑰，沒有 IdP 的組織用它就能補上「能否被複製」那一格。

IdP 帳號是 Google Workspace、Microsoft Entra ID、Okta 這類身分提供者上的帳號，通道服務把驗證交給它；GCP IAP 用的 Google 帳號就是一個實例。Cloudflare Access 可以接任何支援 OIDC 或 SAML（兩種把登入交給 IdP 的標準協定）的 IdP，Teleport 的 Enterprise 版也可以，Community 版的單一登入只接 GitHub。IdP 帳號在分辨個人與留下紀錄上比另外三種好，收回速度則由代理的 session 長度決定：IdP 停用一個帳號之後，代理已經簽給他的 session 或憑證（Cloudflare Access 的 session 最長可以設到一個月、Teleport 的使用者憑證有自己的有效期、gcloud 在本機保存 refresh token）要到期或被撤銷才失效，所以導入時要在代理端設定 session 長度，處理離職或帳號外洩時另外在代理端撤銷 session。選用 IdP 帳號之後，管理通道的風險轉移到那個帳號上，帳號被釣魚，攻擊者就能開通道。所以前提是 IdP 對可以開通道的帳號強制多因素驗證，至少管理員帳號用防釣魚的方式（硬體安全金鑰或 passkey）——一次性驗證碼會在釣魚頁面上被一起騙走。要再收緊時，多數 IdP 與代理服務支援裝置狀態（device posture）條件，例如只允許公司管理的裝置。授權範圍也要一起設計：限定在負責維運的群組、限定可以連的 port 與主機，原則見身分與存取憑證地基 — IAM 模型、OIDC 短期憑證與權限邊界設計的〈最小權限：持續收斂而非一次設定〉。

CI 或自動化工具要使用管理通道時，它的身分是服務帳號或機器身分。長期有效的機器金鑰外洩，等同一把能進所有主機的鑰匙，所以這類身分用 OIDC 換取短期存取憑證，做法見身分與存取憑證地基 — IAM 模型、OIDC 短期憑證與權限邊界設計的〈OIDC：給 CI/CD 的短期憑證〉。

主機登入驗證的做法：SSH 金鑰怎麼發、怎麼收回

sshd 接受哪些金鑰由主機登入驗證決定，而設計的重點是金鑰的生命週期：誰發、多久失效、離職時怎麼收回。

  • 靜態 authorized_keys：公鑰手動或由組態管理工具寫進主機。沒有到期時間，收回要逐台刪除，主機數量一多就難以盤點；金鑰認證的基本設定見 SSH。
  • 由中央服務決定可用的公鑰：主機在登入當下（或登入前由中央服務推送）取得這個帳號可用的公鑰，帳號或角色被移除，下一次登入就失敗。GCP 的 OS Login 在登入當下向 Google 查詢，AWS 的 EC2 Instance Connect 在連線前推送只在短時間內有效的公鑰，兩者都綁定各自的雲端廠商。自建的版本是 sshd 的 AuthorizedKeysCommand 接到 LDAP 或 FreeIPA 這類目錄服務，與廠商無關。這一類都依賴中央服務在登入當下可用：目錄服務或雲端的 metadata server 中斷時，沒有快取的主機一起登不進去；FreeIPA 的用戶端 SSSD 會快取公鑰，目錄服務離線時仍能登入。
  • SSH CA 簽發的短期憑證：主機只信任一把 CA 公鑰（sshd 的 TrustedUserCAKeys），管理員登入前向簽發服務取得一張有效期有限的使用者憑證。憑證過期自動失效，不需要逐台收回；有效期就是能接受的最晚收回延遲。管理員手動簽發時常設成一個工作日左右，讓每天開工時簽一次；簽發由用戶端在連線時自動完成時（Teleport 的 tsh、smallstep 的 step ssh），有效期可以縮到幾小時以內。私鑰外洩而等不到到期時，sshd 用 RevokedKeys 指向撤銷清單提前作廢，這份清單要派送到每一台主機。HashiCorp Vault 的 SSH secrets engine 與 Teleport 都以這種方式運作；OpenSSH 本身就支援，用 ssh-keygen -s 簽發，所以這一種做法同時與廠商無關、又不需要逐台收回；只用 OpenSSH 導入的完整流程見 OpenSSH 內建 CA 的 SSH 憑證導入。

三種做法收回的都是下一次登入；SSH 憑證的「收回」是到期之後失效。已經建立的工作階段不受影響，處理離職或帳號外洩時，管理員要另外登入主機結束那個使用者的工作階段（systemd 的發行版用 loginctl terminate-user <username>），結束已建立工作階段的動作在應用程式的層次叫 session invalidation。

Windows 主機用 RDP 登入時，這一層是 Windows 帳號而不是 SSH 金鑰。本機帳號的收回與靜態 authorized_keys 同類，要逐台停用；主機加入 Active Directory 或 Entra ID 時，登入用網域帳號，停用網域帳號之後下一次登入就失敗，與由中央服務決定公鑰同類。網域主機仍有本機管理員帳號，它的密碼由 Windows LAPS 逐台產生並定期輪替，避免一組密碼通用於所有主機。已經建立的 RDP 工作階段同樣要另外結束（query session 找出工作階段、logoff <session-id> 結束）。

主機登入驗證與通道授權常由同一個系統提供（例如 Teleport 同時做代理與簽發憑證、GCP 的 IAP 與 OS Login 都依 IAM 判斷），但兩者仍然是兩次檢查：通道授權允許開通道，主機登入驗證決定進了通道之後能登入哪個帳號、是否取得 sudo。

移除公開 IP 之後的出站路徑

管理通道改走身分感知代理、VPN 或代理程式反向連線之後，伺服器的公開 IP 對管理用途就不再必要，移除它可以讓主機從網際網路上無法定址。移除之前要先處理主機往外的連線：沒有公開 IP 的主機預設連不到網際網路，套件更新、拉容器映像檔、呼叫第三方 API 都會逾時。

出站需求的對應做法是 NAT：讓內部主機主動往外連、外部無法主動連進來。存取同一家雲端廠商的服務（物件儲存、容器 registry）時，多數廠商提供不經過 NAT 的私有端點，流量不出公網。計費依端點類型不同：GCP 的 Private Google Access 與 AWS 的 Gateway Endpoint（S3、DynamoDB）不另收費，可以省下 NAT 的處理費用；AWS 的 Interface Endpoint 另有按小時與傳輸量的計費。主機還帶著公開 IP 時，雲端廠商的 NAT 不處理這台主機的出站流量，流量走的是它自己的公開 IP，所以在移除公開 IP 之前測出站，結果一定是通的、證明不了 NAT 有效；確認的方式是比對出站時對方看到的來源 IP（例如 curl -s https://ifconfig.me），印出的是 NAT 的 IP 才代表流量走了 NAT。

採用代理程式反向連線的環境，管理通道本身也走出站路徑：代理程式要連到管理服務端點，出站路徑一斷，管理通道也跟著斷。這種中斷不會出現在服務的監控上。收緊出站規則的理由通常與管理通道無關（拿掉 NAT 省費用、限縮出站的目的地），而對外服務的請求不經過代理程式那條連線，服務照常回應；管理通道平時只在除錯時才有人用，除非另外監看管理服務端顯示的代理程式連線狀態，第一個發現它斷掉的人就是下一次要登入主機的人，往往是在事故當下。出站規則若在雲端防火牆上，透過雲端廠商的 API 改得回來，代價是事故處理要等找出並恢復出站路徑之後才能繼續；規則若在主機上的防火牆（ufw、nftables），就只能從救援入口改回來。所以收緊出站規則時，要把管理服務端點列進必須保留的目的地。網站經由 Cloudflare Tunnel 對外時，cloudflared 也是這一類的出站依賴：它用 QUIC 連 Cloudflare 的 UDP 7844、以 http2 連 TCP 7844，實測擋掉 UDP 7844 時 quick tunnel 一直重試 QUIC 而沒有改用 http2，網站回 Cloudflare 的 530，見 Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠 的〈Cloudflare Tunnel：源站不開入站，以及出站要放行的連接埠〉。

對外提供服務的主機（網站、API）移除公開 IP 之前，要先把流量入口換到負載平衡器，見流量入口層 — 請求怎麼從使用者到達應用。

切換管理通道時避免把自己鎖在外面

切換管理通道的順序由一個事實決定：舊路徑被移除的那一刻起，所有走舊路徑的連線都會被拒絕，包括正在操作的管理員自己的連線。所以新路徑要在舊路徑還在的時候建好並驗證，才移除舊路徑，這個順序在網路變更上叫 make-before-break。順序是：救援入口先準備好並實際登入過一次（做法見〈救援入口：管理通道斷掉時的備用路徑〉），同時開啟舊路徑的紀錄開始觀察，接著建新通道、每一位管理員都用自己的身分實際連通一次，等觀察期涵蓋過一次完整的部署週期之後遷移非人員的來源，然後停用舊路徑驗證新路徑，最後才刪除舊路徑。

走舊路徑的不只管理員。CI 或部署腳本用公開 IP 直連主機、組態管理工具、監控探測、第三方廠商的維護連線，都會在舊路徑移除時一起中斷。全開規則的防火牆紀錄大部分是網際網路掃描程式的來源，CI 託管執行環境的 IP 每次不同，混在裡面認不出來，所以防火牆紀錄只用來列出候選來源；實際依賴舊路徑的連線要從主機的認證紀錄裡找成功登入的那幾筆：sshd 的 Accepted publickey for <user> from <ip> 帶著登入的帳號與金鑰指紋，Windows 的事件 ID 4624（登入類型 10 是 RDP）帶著登入的帳號。觀察期要涵蓋一次完整的部署週期與排程工作，找出來的非人員來源先改走新通道（機器身分用短期存取憑證開通道）。

舊路徑還在時，連通測試在兩種情形下會誤報成功。主機同時有公開 IP 與新通道時，連線工具可能優先走舊的直連路徑，所以測試要用工具的強制參數走新路徑（GCP 上是 gcloud compute ssh --tunnel-through-iap）。即使連線確實走了新通道，舊的全開規則（來源 0.0.0.0/0）也同時放行代理的位址段，放行這次測試連線的可能是舊規則，新規則寫錯了也測不出來。驗證新規則要先停用舊規則再測一次——停用的規則一行指令就能恢復原樣，刪除之後要重新建立、重建時可能寫錯——或查防火牆紀錄裡這次連線命中的是哪一條規則；防火牆沒有停用功能時，改用查紀錄這一種。規則在雲端防火牆上時，停用之後 SSH 連不上，管理員仍然能透過雲端廠商的 API 還原。規則在主機上的防火牆時，停用或改錯就只剩救援入口能進去，所以改之前先排一個自動還原：iptables-apply 套用新規則之後要操作者在時限內確認、逾時就自動回到舊規則，用 ufw 或 nftables 時用 at 排一個幾分鐘後還原的工作，確認新路徑可用再取消它。

用 IaC 管防火牆的環境，切換要改在程式碼裡，落差有兩個方向：只在網頁管理介面或 CLI 刪掉的規則，IaC 工具下一次執行 apply 時會依程式碼建回來；只在 CLI 新增的設定（新規則、主機上的 tag、IAM 授權、metadata），所屬資源若在程式碼裡被完整定義，下一次 apply 會把它拿掉，舊規則這時已經刪了，新通道跟著消失。這種落差叫 drift，處置的方式見兩套真相並存的過渡期操作。在 CLI 上停用舊規則做驗證的期間，要暫停所有 apply，否則驗證中的規則會被改回去。

救援入口：管理通道斷掉時的備用路徑

管理通道的任何一層出錯——防火牆規則寫錯、代理服務的權限設錯、sshd 設定改壞、磁碟滿導致 sshd 起不來——管理員就進不了主機。救援入口是一條不經過主機作業系統的網路設定與 sshd 的路徑：雲端廠商的序列主控台（serial console）（GCP 的 Serial Console、AWS 的 EC2 Serial Console、Oracle Cloud 的 serial console connection）、VPS 商在管理面板提供、在瀏覽器裡顯示主機畫面的 VNC 主控台，以及地端主機的 IPMI、iDRAC 這類嵌在主機板上的頻外管理控制器（out-of-band management；其他中文資料常寫作「帶外管理」）。頻外管理控制器有自己的網路埠，它的網路要接在獨立的管理網段。救援入口不經過管理通道那三層的設定，但它有自己的授權：雲端上是雲端帳號的 IAM 權限與開啟它的開關，登入時用主機上的本機帳號密碼。

救援入口本身也是一個能登入主機的入口，所以它的設計與管理通道相反：平時保持關閉或只授權給少數持有救援責任的帳號，只在救援時對單一主機開啟，用完關回去。組織層級預設關閉救援入口時，救援名單裡要有能對那台主機所在的專案或帳號解除這項限制的人，否則事故當下只有主機權限的人開不了它。這種「平時不存在、事故時才開、事後回顧」的權限叫 break-glass access，工單、時限與事後回顧的做法見團隊權限分級與存取管理的〈臨時提權（break-glass）〉。

序列主控台與 VNC 主控台多半用主機上的本機帳號密碼登入，所以救援帳號要在主機還正常時就建好：密碼由密碼管理工具逐台隨機產生並存在受控的密碼庫，sshd 仍然維持只收金鑰（PasswordAuthentication no），持有救援密碼的人離開時輪替，並在切換管理通道之前用它實際登入一次，確認帳號、密碼與 sudo 都可用。地端與部分 VPS 沒有事先建好的帳號時，主機內部沒有任何不經登入的寫入路徑，只能重開機進單人模式或掛救援映像檔。雲端 VM 另外有不需要事先建帳號的修復路徑：GCP 在 metadata 設的 startup-script 每次開機都以 root 執行（Linux VM 用 startup-script 這個鍵），可以用來建帳號或改回 sshd 設定；AWS 的 user-data 預設只在第一次開機執行，要拿來救援得改成每次開機都執行的 cloud-init 格式；GCP、AWS 與 Oracle Cloud 都可以把開機磁碟卸下、掛到另一台 VM 修改再掛回去。這幾條路徑都要重開機或停機，比事先建好的帳號慢。不必重開機的路徑是業者在主機裡執行指令的服務：AWS 的 SSM Run Command，以及 Oracle Cloud 的 Run Command。Oracle Cloud 的 Run Command 以 ocarun 這個使用者執行腳本，要改 sshd 設定或別的帳號的 authorized_keys，得事先在主機上替 ocarun 設好 sudo（官方列的做法是建立時用 cloud-init 設，或建好之後登入主機設）。兩者都靠主機上的代理程式執行，代理程式沒在運作、或連不到業者的服務端點時用不上。Oracle Cloud 上序列主控台、Run Command、掛開機磁碟與重建這幾個入口各自要事先準備什麼，見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈建立之後加金鑰與金鑰遺失時的入口〉。救援工作階段不經過平時錄製操作的位置，有逐指令稽核要求的環境，要在事後把救援時做了什麼另外記錄下來。

組織層級的護欄與稽核紀錄

單一專案或帳號的收斂只保護那一處，下一個新建的專案仍可能帶著對外開放的管理 port。組織層級的護欄有兩種：限制資源能被建成什麼樣子（禁止建立帶公開 IP 的主機、不讓預設網路與它的全開規則被自動建立、強制主機登入驗證改用中央服務提供公鑰、預設關閉序列主控台），以及在組織層級評估、優先於專案規則的防火牆政策，讓專案裡即使建出來源是 0.0.0.0/0 的管理 port 規則，它也不生效。IaC 環境另外可以在 PR 階段用 checkov 這類工具擋下全開規則，見 infra 走 PR 流程的〈tflint / checkov / tfsec：抓壞寫法與安全漏洞〉。

稽核紀錄（audit log）是在事後用到的：主機上出現沒人認領的設定變更、某把私鑰被回報外洩而要知道它在外洩之後有沒有被用過、成員離職後要確認他的存取確實停了。這些時刻要查的是三項紀錄：誰在什麼時候經由哪條通道登入了哪台主機、誰在什麼時候開了救援入口、環境裡是否出現新的對外開放管理 port（新建的專案或主機照預設建出全開規則，是這一項最常見的來源）。防火牆紀錄只看得到來源位址；走代理的環境，來源位址都是代理的位址段，要知道是哪個人，得靠通道授權那一層的紀錄（代理服務或 IdP 的 audit log），或主機登入驗證那一層的紀錄（每人一把時的金鑰指紋、SSH 憑證的識別字串、OS Login 的使用者名稱）。通道授權用來源 IP 時，「是誰」只剩 sshd 紀錄裡的金鑰指紋可查，而且只在每人一把金鑰時對得到人。這些紀錄多半要事先開啟，只記錄開啟之後的事，所以在切換管理通道的同一天開啟。代理服務記的多半是誰在什麼時候開了通道，不記錄通道裡執行的指令；要逐指令的紀錄，得用有工作階段錄製功能的代理或跳板機（見下面〈錄製操作與不開管理 port 的要求〉）。AWS 上對外開放規則的盤點方法見 Security Group 稽核與清理。

三層做法的選擇：依存取者與主機擁有者的關係、主機分布、收回方式與開放時間挑選跳板機、VPN、身分感知代理與 SSH 憑證

選擇三層做法的順序，與封包通過三層的順序不同。封包先過網路可達性，而設計時先定下的是通道授權的身分來源，也就是通道授權判斷「這個人是誰」時查的那個帳號系統，因為網路可達性與主機登入驗證能用哪些服務，由身分來源篩出來：一個只認 Google 帳號的代理，組織的身分在 Entra ID 時，要先把身分同步或聯合（federation）進 Google 的帳號系統才用得了；OS Login 這類由中央提供公鑰的做法，前提是登入者的身分已經在提供這項服務的雲端廠商的 IAM 裡。所以下面依身分來源、網路可達性、主機登入驗證的順序，說明環境的哪一項條件會排除哪些做法；同一批主機有多種存取者時怎麼合併、錄製操作與不開管理 port 這兩種需求怎麼改變結果，各有一節；通道平時要不要開著，放在最後一節。

通道授權的身分來源：存取者與主機擁有者的關係、身分所在的帳號系統

分開各種存取者的軸有三件事：存取者是人還是機器（機器不經過登入畫面）、存取者與主機擁有者是不是同一方，以及存取者的身分放在哪個帳號系統裡。依這三件事，存取者分成組織成員、外部合作方、個人與機器四類，各類的身分來源不同。四類都走完之後，若結果是「沒有任何可用的帳號系統」，就落在本節最後一段的處境。

組織成員（主機擁有者自己的人）的身分在組織的 IdP 上時，通道授權用 IdP 帳號，前提是 IdP 對可以開通道的帳號強制多因素驗證，至少管理員帳號用防釣魚的方式（見〈通道授權的做法〉）。通道服務認的帳號系統與 IdP 不是同一家時有兩條路：把 IdP 的帳號聯合進那個帳號系統（例如讓 Google 的 Cloud Identity 以 SAML 單一登入接 Entra ID 或 Okta，並由 IdP 把帳號同步進去，使用者在原本的 IdP 登入、拿到的是那家雲端認得的身分），或改選一個直接接這個 IdP 的通道服務（Cloudflare Access、Teleport Enterprise）。兩條路怎麼選要看主機分布在哪裡：主機全在同一家雲端時，聯合進那家雲端是常見的選擇，代價是要維運同步與單一登入的設定；主機跨多個環境時，直接接 IdP 的通道服務一套就涵蓋全部。

外部合作方（外包團隊、維護廠商，主機屬於委託他們的組織）的身分來源有三種狀態，由主機擁有者決定：

  • 主機擁有者替他們建帳號（Entra 的 B2B 訪客、在 Cloud Identity 替外包人員建的帳號）：外部人員走組織成員那一條，多因素驗證也由主機擁有者強制；合約到期時停用帳號，或把授權設成有期限的綁定。
  • 主機擁有者授權給他們自己的帳號（外部人員公司或個人的 Google 帳號）：部分通道服務接受，GCP 上要另外授予外部帳號登入 VM 的角色，而組織若限制 IAM 綁定只能用自己網域的成員，這種授權會被拒絕（指令見 GCP 篇〈IAP 的 IAM 授權範圍：誰拿得到通道〉）。組織 IdP 的多因素驗證強制管不到這些帳號，採用前要確認對方帳號的驗證方式。
  • 兩者都不行：外部人員落在沒有可用帳號系統的處境（見本節最後一段）。合約結束、整個團隊一起離場是收回權限的時間點，所以要有一份清單，列出所有主機上屬於這個團隊的金鑰，或改用由主機擁有者的 SSH CA 簽發、會到期的 SSH 憑證（見〈主機登入驗證：登入權限的收回靠人工刪除、帳號連動或到期〉）。

個人（一個人管理屬於自己的一台或幾台主機）用的身分是自己在 GitHub 或 Google 的個人帳號，這個帳號就是通道授權的依據，所以它同樣要開多因素驗證，能用硬體安全金鑰或 passkey 就用。主機屬於客戶時不是這一類，那是外部合作方：用個人帳號把客戶的主機接進自己的 tailnet 或 Cloudflare 帳號，主機擁有者就失去控制，合約結束時也沒有收回的位置。主機在自己申請的雲端帳號裡時，身分已經在那一家的 IAM 裡，可以直接用那一家的代理（GCP 的 IAP、Oracle Cloud 的 Bastion、AWS 的 Session Manager），建立主機時的選法見 網路：subnet、私有 IP、公開 IP 與防火牆規則 的〈虛擬網路與 subnet：主機放在哪一段網路〉；自己有固定的對外 IP 時，來源 IP 白名單也可以用。主機分散在不同業者或家裡的機器上時，跳板機只是多開一台對外的主機，這時的選擇是 mesh VPN 或以個人帳號登入的代理程式反向連線（Cloudflare Tunnel 搭配 Access）：除了 SSH 還要連主機上其他 port、而且每台要連的裝置都能裝用戶端時選 mesh VPN；想從瀏覽器或沒裝用戶端的裝置登入時選反向連線，代價是依賴 Cloudflare 營運的服務。兩者更完整的取捨見 7.C11 選型：單人遠端 Shell — Tailscale vs Cloudflare Tunnel。

機器（CI、Ansible 這類組態管理工具、監控探測）的身分不經過 IdP 的登入畫面，放在雲端的服務帳號上。跑在 CI 平台上的機器，用 CI 平台簽發的 OIDC token 換成服務帳號的身分（GCP 與 AWS 都稱為 workload identity federation，概念見 Workload Identity，做法見〈通道授權的做法〉最後一段）；跑在雲端 VM 上的機器（一台定期執行 Ansible 的控制主機），用那台 VM 掛的服務帳號。收回是撤掉那個服務帳號的授權。主機登入驗證用 OS Login 這類帳號連動的做法、或 SSH 憑證時，機器不必持有長期金鑰；用靜態 authorized_keys 時，機器手上的 SSH 私鑰仍然長期有效，要定期輪替。

沒有任何可用的帳號系統時，分兩種情形。主機擁有者有 IdP、只是不給外部人員帳號時，直接從下面的白名單、VPN 與跳板機裡選。組織自己還沒有 IdP 時，先比較建一個的成本：要比較的是每人一把金鑰的清單要逐台維護的工作量（人數乘以主機數、人員異動的頻率），以及稽核需不需要「是誰」的紀錄，對上建立 IdP 的成本（Google 的 Cloud Identity 免費版、把 GitHub 組織當 IdP 用）與替每個人設定多因素驗證的工作。決定不建時，管理員有固定的對外 IP 就用來源 IP 白名單，代價是分辨不出個人，「是誰」只能靠每人一把、登錄在主機 authorized_keys 的使用者金鑰的指紋追。沒有固定的對外 IP（遠端工作的小團隊、外包團隊維護客戶的幾台主機）時白名單縮不下來，剩下 VPN 與跳板機兩種：除了 SSH 還要連其他內部服務時選 VPN，每個人用自己的 VPN 憑證；主機有多台、只需要 SSH、或要集中錄製操作時選跳板機，每個人在跳板機上用一把金鑰、在目的主機上用另一把。每人一張憑證或一把金鑰時，〈通道授權的做法〉那張表裡的分辨個人與「是誰」的紀錄都做得到，代價是靠人工維護那份清單。

網路可達性：主機分布與代理把連線送進主機的方式

這一步的輸入是〈通道授權的身分來源〉的結果（身分落在哪個帳號系統、哪些通道服務認得它）與主機分布在哪裡。

身分落在主機擁有者的通道服務認得的帳號系統時（組織成員、主機擁有者替外部人員建的帳號、主機擁有者授權給外部人員自己的帳號、機器的服務帳號），選擇取決於代理怎麼把連線送進主機。這些通道服務都開在主機擁有者的帳號底下，外部人員只是被授權使用。代理從自己的固定位址段連到主機內部 IP 時（GCP 的 IAP），它只到得了從那家雲端網路路由得到的主機：同一家雲端裡的主機，以及經專線或 VPN 接進那家雲端網路、而且雲端的路由器有對地端通告代理位址段的地端主機；兩種主機都要那家的代理認得這個身分（直接認得，或經由〈通道授權的身分來源〉說的聯合）。代理經由主機上的代理程式反向連線時（Cloudflare Access、Teleport），任何有出站路徑的主機都接得上，跨雲、地端與不提供代理服務的 VPS 商都落在這一類，一套通道授權涵蓋所有環境；反向連線的前提換成那條出站路徑，見〈移除公開 IP 之後的出站路徑〉。AWS 的 SSM Session Manager 也能管理地端主機（在主機上安裝代理程式並註冊為受管節點），但通道授權只認 AWS 的 IAM。接 IdP 的 mesh VPN（Tailscale、NetBird）同樣涵蓋所有環境，適合除了 SSH 還要連其他內部服務的團隊。主機全在同一家雲端、而且只需要 SSH 與 RDP 時，用那家雲端的代理（GCP 的 IAP）：身分已經在那家的 IAM 裡，主機登入驗證也能接同一套帳號（OS Login），不必另外維運代理或 VPN。

不想依賴第三方服務時，代理可以自己架設，代價是代理本身成為組織自己維運、對網際網路開放的入口（見〈錄製操作與不開管理 port 的要求〉）：HashiCorp Boundary 的社群版與 Pomerium 都能接任何 OIDC IdP。Teleport Community 版也能自架，但單一登入只接 GitHub（另有 Teleport 自己的本機帳號），接 OIDC 或 SAML 的 IdP 要 Enterprise 版；而且從 Teleport 16 起，它的授權只允許員工少於 100 人、年營收低於 1,000 萬美元的公司使用（兩個條件都要符合，個人使用不受限），超過的組織要用 Enterprise 版。cloudflared 依賴 Cloudflare 營運的服務。

存取者屬於「個人」這一類（主機屬於自己）、或沒有任何可用的帳號系統時，網路可達性在〈通道授權的身分來源〉已經定了：個人在 mesh VPN 與反向連線之間選，沒有帳號系統的處境在白名單、VPN 與跳板機之間選。

同一批主機有多種存取者時

同一批主機常同時有員工、外包與 CI 要連。通道授權可以依存取者各自不同，網路可達性卻不行：一台主機對網際網路的暴露面，由所有存取者用的路徑裡最寬的那一條決定。員工改走 IAP、外包仍走公開的跳板機時，主機仍然能從網際網路經由那台跳板機觸及，員工那條路的收斂就被抵銷了。所以合併的做法是讓每一類存取者都走同一條路：替外包人員建帳號、或把他們自己的帳號授權進主機擁有者的通道服務，讓他們和員工一起走 IAP；機器以服務帳號走同一個代理。兩種帳號都拿不到的那一類，用主機擁有者自己維運、以金鑰認證、不回應未通過驗證的封包的 VPN（WireGuard），金鑰由主機擁有者發給每一個人；mesh VPN 與反向連線也行，但要開在主機擁有者的帳號底下、由主機擁有者授權，不是開在外部人員自己的帳號裡。主機登入驗證也照同一個原則合併：同一台主機上混用兩種做法（例如員工用 OS Login、外包用 SSH 憑證）會讓收回分散在兩處，能不能並存也依實作而定（OS Login 啟用之後，sshd 的設定由 guest agent 管理），所以先讓所有存取者落在同一種做法。

錄製操作與不開管理 port 的要求

不論主機在哪裡，有兩種需求會改變上面的結果。

要集中錄製管理員在主機上執行了什麼時（需要這種錄製的情境例如外部廠商或外包人員要登入組織的主機、內部稽核要求留下逐指令的操作內容而不只是登入紀錄），錄製要有一個所有工作階段都經過的位置：有工作階段錄製功能的代理（Teleport 錄製每一個 SSH 工作階段），或跳板機。選了跳板機時，身分來源仍然沿用〈通道授權的身分來源〉選定的那一個：有 IdP 的組織架一個接 IdP 登入的 SSH CA，管理員登入 IdP 換到短期 SSH 憑證，跳板機只信任這個 CA。沒有 IdP、或外部人員拿不到帳號時，由主機擁有者的 SSH CA 依人簽發短期憑證，憑證的識別字串寫進錄製紀錄，做法與〈主機登入驗證：登入權限的收回靠人工刪除、帳號連動或到期〉的外包團隊相同。跳板機退回每人一把靜態金鑰的話，錄製是有了，隨帳號收回的能力卻沒了。GCP 的 IAP 這類代理只記錄誰開了通道，不錄製通道裡的指令。

需求是「沒有任何主機對網際網路開管理 port」（客戶或稽核常這樣要求）時，這個需求要防的是一個由組織自己維運、在網際網路上監聽、而且會回應沒有通過認證的來源的入口：sshd、SSL VPN 設備與自架代理的對外端點都是這種入口，掃描程式找得到它，認證之前的漏洞也打得到它。代理服務的邊緣節點同樣回應未認證的來源，差別在它由廠商維運，修補的責任跟著移到廠商身上。依這個判斷，跳板機與來源 IP 白名單都不符合：跳板機本身仍對外開著 22 port，白名單則是每台主機都對外開著 22 port、只是限制了來源；組織自己維運的 SSL VPN 與 IPsec 閘道，以及自架、對網際網路開放的 Teleport、Boundary、Pomerium 的 proxy 也不符合。符合的是廠商維運的代理程式反向連線、mesh VPN（裝置之間以 NAT traversal 連線，協調伺服器由廠商維運）、從代理位址段連入的身分感知代理（主機只接受代理位址的入站，對外監聽的是廠商的代理服務），以及 WireGuard：它在主機上開一個 UDP port，但不回應沒有通過金鑰驗證的封包，掃描程式看不到它在監聽。WireGuard 與 mesh VPN 算不算符合，取決於提出需求的一方怎麼定義「開管理 port」，採用前要跟客戶或稽核確認。

兩個需求同時成立時（受稽核的金融業常見），符合的組合有兩種：一種是有工作階段錄製功能、而且以反向連線或代理位址段把連線送進主機的代理，例如 Teleport Enterprise 的廠商代管版（Teleport Cloud：proxy 由廠商維運，節點以反向通道連到 proxy、錄製每個工作階段、接 Entra ID 或 Okta）；自架的 Teleport proxy 本身就是對網際網路開放的入口，不符合不開管理 port 的需求；另一種是沒有公開 IP、放在內部網段的跳板機負責錄製，管理員經由 IAP 或反向連線的代理連到這台跳板機。救援工作階段不經過這兩種錄製位置，處理方式見〈救援入口：管理通道斷掉時的備用路徑〉。

主機登入驗證：登入權限的收回靠人工刪除、帳號連動或到期

網路可達性選了直接在主機上開 shell 或自帶 SSH 伺服器的做法（SSM Session Manager 的預設模式、Tailscale SSH、Teleport 的節點）時，sshd 不在路徑上，這一層改由那個服務的權限設定承擔。其餘情形，主機登入驗證的選擇取決於登入權限的收回靠什麼發生：

  • 收回靠人工刪除（靜態 authorized_keys）：成立的條件是主機少、人員穩定，而且收回已經是離職與合約結束交接流程裡的一項。
  • 收回靠帳號連動（由中央服務決定公鑰）：已經用某家廠商的 IdP、而那家廠商提供依同一個身分判斷的公鑰服務（GCP 的 OS Login）時，不必另建簽發服務或金鑰派送流程，收回跟著帳號走；它綁定那家廠商，主機在別的環境就用不了。自建的 AuthorizedKeysCommand 接 LDAP 或 FreeIPA 跨環境也做得到，代價是每台主機登入時都要連得到目錄服務，主機端沒有快取時（FreeIPA 的用戶端 SSSD 會在主機上快取公鑰），目錄服務中斷所有主機一起登不進去。
  • 收回靠到期（SSH 憑證）：主機跨多個環境（不同雲端、地端、不同 VPS 商，各自管理金鑰的主機群）時，它不依賴任何一家雲端廠商的帳號系統，也不必逐台收回，代價是要維運一個簽發服務並保管 CA 私鑰；私鑰外洩而要提前作廢時，撤銷清單仍要派送到每一台主機。SSH 憑證也適用於人員流動高、而且進不了客戶帳號系統的外包團隊：由主機擁有者的 CA 每天簽發、有效期設成一個工作日左右，合約結束時停止簽發，最後一張憑證在一個有效期之內失效，不必逐台盤點金鑰。
  • Windows 主機（RDP）：主機加入 Active Directory 或 Entra ID 時，登入用網域帳號，收回跟著網域帳號走，屬於帳號連動；沒有網域時（例如組織只有 Google Workspace），每個管理員在每台主機上各建一個本機帳號、不共用，收回靠人工逐台停用。本機管理員帳號的密碼在有網域時用 Windows LAPS 逐台產生並輪替，沒有網域時用密碼管理工具逐台產生；Windows 主機多的組織，把主機加入 Entra ID 通常比逐台維護本機帳號省事。

不可變基礎設施下的臨時授權：通道平時關閉

服務已經用不可變基礎設施（immutable infrastructure）的方式部署，也就是以重新建立主機取代登入修改時，管理通道只在除錯與救援時才用得到。這時可以讓通道平時對任何人都開不起來：管理員平時移除通道授權的權限綁定，除錯時才臨時授予，用完收回；這一整個循環叫 just-in-time access，授予與收回的流程與救援入口相同，見〈救援入口：管理通道斷掉時的備用路徑〉。主機由 managed instance group 或 GKE 這類機制依 template 重建時，救援也多半改成重建一台而不是登入修，重建、退回舊版 template 與登入修各自適用的情形見GCP 上由 MIG 與 GKE 管理的 VM 的管理存取，重建一台 VM 的指令與實測結果見 GCP 上 MIG 與 GKE 管理存取的實測紀錄 的〈重建一台壞掉的 VM：recreate-instances 與重建之後的主機金鑰〉。

AWS 與 Oracle Cloud 上對應的元件

這篇提到的 AWS 元件按層列在這裡，方便對照：網路可達性有 SSM Session Manager（代理程式反向連線）、EC2 Instance Connect Endpoint（從代理位址連入，支援原生 SSH 與 RDP）與 security group（防火牆規則）；通道授權由 AWS IAM 決定誰能開 Session Manager 的工作階段或使用 Instance Connect Endpoint；主機登入驗證有 EC2 Instance Connect（推送短效公鑰）；出站路徑有 NAT Gateway 與 VPC Endpoint；救援入口是 EC2 Serial Console；組織層級的護欄是 AWS Organizations 的 SCP。規則的盤點方式見 Security Group 稽核與清理。

Oracle Cloud 的 Bastion 名字跟跳板機相同，位置在這張地圖上卻不一樣。它是業者託管的服務，不是放在公開網段、對外開 22 port 的那台主機：官方說明 Bastion 位在公開 subnet，替使用者建好連到私有 subnet 裡目標主機所需的網路設施，主機不需要公開 IP，所以它承擔網路可達性；誰能建立工作階段由 Oracle Cloud 的 IAM 政策決定，這是通道授權。Bastion 的工作階段共有三種：managed SSH session 由主機上的代理程式臨時放進一把公鑰，承擔主機登入驗證，而官方列出 Arm 架構的 A1 機型加非 Oracle Linux 的主機不支援這一種，Oracle Linux 也要選代理程式提供 Bastion plugin 的版本（支援範圍與查法見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈不放金鑰時的登入服務〉）；SSH port forwarding session 只承擔網路可達性與通道授權，主機登入驗證仍然是主機自己的 sshd 與 authorized_keys；dynamic port forwarding（SOCKS5）session 同樣不經過代理程式，轉接的目標不固定，可以動態連到私有 subnet 裡的任何資源。私有 subnet 裡的主機要用 managed SSH session，VCN 要有服務閘道之類的閘道與路由，實際的網路設定見 Oracle Cloud 建立主機的實測紀錄 的〈進建立頁之前：compartment、VCN、閘道與 private subnet〉。各欄位怎麼設定見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈不放金鑰時的登入服務〉，金鑰遺失時 Oracle Cloud 的救援入口（序列主控台、Run Command、把開機磁碟掛到另一台主機修改）見同一篇的〈建立之後加金鑰與金鑰遺失時的入口〉。〈移除公開 IP 之後的出站路徑〉在 Oracle Cloud 上的實作（私有 subnet 的主機加 NAT gateway、路由規則與只掛在那台主機上的出站 NSG），見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈加出站：NAT gateway、路由規則與只掛在這台主機上的 NSG〉。

延伸閱讀：GCP 上的實作與反向連線的運作細節