GCP帳號代充值 GCP 新加坡實例 SSH 連線失敗拒絕訪問修復

第一章：先把問題定性——「拒絕訪問」到底拒在哪裡

在 GCP 上遇到「SSH 連線失敗：拒絕訪問」，很多人第一反應是重設 SSH 金鑰或換密碼，但實務上這類錯誤常常不是單一原因。你看到的「拒絕訪問」可能是：

1）網路層被拒：例如防火牆沒放行 22/TCP，或你所在來源 IP 沒在允許列表。

GCP帳號代充值 2）認證層拒絕：例如 OS Login 未開啟或帳號未授權，或公鑰不在正確位置、金鑰類型不相容。

3）服務端層拒絕：例如 sshd 設定禁止密碼、允許的用戶/群組不同，或 /home 目錄權限不正確。

GCP帳號代充值 要修得快，關鍵在於先判斷「拒絕發生在哪一步」。把你手上的錯誤訊息整理出來，例如：連線是否能建立但認證失敗？還是根本連不上主機（逾時/No route/Connection refused）？

GCP帳號代充值 接下來我用一個貼近現場的流程，從最常見的「外部連線被擋」開始查起，再走到「金鑰與帳號授權」最後到「sshd 本機設定」。文章以 GCP 新加坡（asia-southeast1）區域的 Compute Engine 實例為例，但方法對所有區域一致。

第二章：確認你到底是「公網」還是「內網」在連線

很多「拒絕訪問」其實是因為你用錯連線方式。GCP 的虛擬機同時有內部 IP（private IP）與外部 IP（public IP）。外部 SSH 通常需要：

1）實例有外部 IP（或你使用了 IAP/堡壘機）。

2）防火牆允許來源 IP 對應的 22/TCP。

3）目的主機的 sshd 正常運作。

如果你打算從公司網路、家用網路直接連進去，請優先確認你的 SSH 指令使用的是外部 IP 或域名，而不是內網 IP。反之，如果你在同一個 VPC 內用內網 IP 連線，那麼防火牆與路由要以內網規則為準。

簡單做法是：在本機上先測連線是否通，例如看你是拿到「timeout」還是「connection refused」。timeout 常見於防火牆或路由問題；refused 往往代表目標主機端口回了拒絕（sshd 沒啟或被 local firewall 擋）。

第三章：先看防火牆——最常見的根因

在 GCP，Compute Engine 的防火牆主要是「VPC 防火牆規則」。你要特別注意它們的方向、目標與來源。

3.1 檢查防火牆規則的方向：INGRESS 才會影響 SSH

SSH 是從你那台電腦進到實例，因此只看入站（INGRESS）規則。若你在規則裡看到的是 EGRESS，對 SSH 沒有直接幫助。

3.2 檢查你放行的是不是 22/TCP

許多團隊會寫寬鬆的規則，例如放行 0-65535，但也有人只允許特定端口。你要確認規則包含：

protocol：tcp

ports：22

不要只看「ssh」字樣，有些規則可能綁的是別的預設集合或實際 ports 欄位不是 22。

3.3 檢查目標：是不是套到你的實例

防火牆規則通常有 target tag 或 target service account。你的實例可能沒有打上那個 network tag，或 service account 不一致，導致規則看似存在但實際沒套用。

你需要把實例的 network tags（網路標籤）與防火牆規則設定對起來，或檢查規則是否以 service account 方式指定目標。

3.4 檢查來源來源：來源 IP 是否正確

GCP帳號代充值 最容易忽略的是來源（source）。很多時候規則寫成允許某個段，但你實際連線的來源不是那個段。GCP 的來源可用：

1）IP ranges（例如 203.0.113.0/24）

2）service account / 其他定義（視場景）

如果你用手機熱點或公司網路切換，來源 IP 可能變了。這時你會覺得「我明明有金鑰，為什麼還是拒絕」。其實不是金鑰問題，是防火牆層在擋。

臨時排查時，你可以暫時放寬來源到你的確定來源 IP（而不是 0.0.0.0/0）。排查完成後要收回，避免安全風險。

第四章：如果防火牆沒問題，接著查「OS Login」與帳號授權

當網路能通時，下一關就是認證。GCP 的 OS Login（通常也稱為 Google Cloud OS Login）會影響你如何把金鑰放到 VM 上。你可能以為自己把公鑰寫進了 ~/.ssh/authorized_keys，但系統其實用的是 OS Login 的機制，導致你的檔案不生效或帳號權限不足。

4.1 你連線用的是哪個帳號？帳號要對

常見錯誤是你用錯使用者，例如：

你用 ssh -i key user@ip，但 VM 實際允許的是另一個預設帳號（例如 image 建立時的 ubuntu、debian、centos）。

如果你登入帳號不存在，sshd 也可能回覆不同錯誤訊息。你看到的「拒絕訪問」要對應到正確帳號。

4.2 檢查 OS Login 是否啟用與你授權了沒有

若 OS Login 開啟，GCP 會從你帳號所屬的權限與元資料把金鑰管理起來。你需要在 IAM 端確保你有足夠權限，且你的 Google 帳號已被允許。沒有授權時，即使你把本機金鑰存在 VM 上，也可能無法登入。

有些情況下，OS Login 的設定也會限制用戶的 sudo、禁止某些登入方式。最直接是確認：你是否看到「Welcome」並要求密碼，或是直接被拒絕。

4.3 舊金鑰仍在？確認你用的公鑰指紋是否一致

許多人換了本機 keypair，但以為 VM 仍使用舊 key；或相反。你可以對照本機 key 的指紋與伺服器上的金鑰是否一致（若你能登入或能查到）。

即使不做指紋比對，觀念上也要記住：SSH 不是「密碼」層的問題，就是「公鑰是否匹配」。只要金鑰不匹配，就會被拒絕。

第五章：查 sshed 設定——認證被擋在服務端

當你確認防火牆放行、網路可達、帳號與金鑰機制（OS Login/authorized_keys）看起來也沒問題，接著才是 sshd 本機設定。

GCP帳號代充值 5.1 檢查 sshd 是否真的在跑

你可能會遇到「端口看起來開了，但連線會很快失敗」或反之。若 sshd 沒啟動，你就會看到拒絕。

若你能用 GCP 的串連方式（例如透過序列埠、或使用替代通道如 IAP）進入救援模式，就能檢查：

systemctl status ssh 或 equivalent

並確保 sshd 服務正常。

5.2 檢查允許登入的方式：PasswordAuthentication、PubkeyAuthentication

有些系統被安全加固後，禁止密碼登入，只允許金鑰。若你當時用的是密碼方式就會被拒。

另一種相反狀況是禁止公鑰登入。這在不常見，但在強制策略環境會發生。你可以檢查 /etc/ssh/sshd_config 相關項目，例如：

PubkeyAuthentication

PasswordAuthentication

AuthenticationMethods

以及是否啟用了 ForceCommand、AllowUsers、DenyUsers 等限制。

5.3 檢查 home 目錄權限與 authorized_keys 權限

SSH 對權限非常敏感。常見錯誤是：

~/.ssh 權限過寬

authorized_keys 權限不正確

檔案所有者不是目標用戶

當權限不符合預期時，sshd 可能會忽略 authorized_keys，導致你永遠登入失敗。

GCP帳號代充值 標準做法是確保：

~/.ssh 的權限通常是 700

GCP帳號代充值 authorized_keys 權限通常是 600

且 owner 是目標用戶。

第六章：用系統化步驟定位——避免「猜」

你可以把排查流程當作一張檢查表。下面每一步都對應一類錯誤訊號，能顯著縮短時間。

6.1 第一步：判斷連線是否可建立

如果連線本身逾時（timeout），優先懷疑：

防火牆未放行 22/TCP

來源 IP 不在允許範圍

實例沒有外部 IP（若你用外部連線）

或路由/網段不通。

如果顯示 connection refused，則可能是：

sshd 沒在跑

或本機防火牆拒絕。

6.2 第二步：確認防火牆是否真的套用到這個實例

很多人只檢查了規則是否存在，卻沒核對 target tag/service account。你要回到實例頁面確認 network tag 與 service account。

只要其中一個條件不符合，規則就不會影響這台 VM。

6.3 第三步：驗證你登入的帳號與金鑰來源機制

如果你開了 OS Login，就要在 IAM 做授權，而不是只改 VM 上的 authorized_keys。

如果你沒開 OS Login，就要檢查 VM 上的 authorized_keys、權限與所有者。

6.4 第四步：在服務端看 sshd 日誌

當網路與金鑰仍不通，日誌會告訴你「拒絕原因」。你可以查看 sshd 日誌，關鍵字通常包含 failed, authentication 或拒絕的用戶。

日誌是避免盲猜的核心。看到日誌就能知道是金鑰不對、用戶不允許、還是權限導致忽略。

第七章：幾個新加坡實例常見「陷阱」

地域本身並不會改變 SSH 邏輯，但實務上在新加坡區常會出現一些管理上的落差，尤其是多環境部署時。

7.1 多環境同名但防火牆不同

你可能在 production 用了一套防火牆，測試用另一套。名稱相似、但 network tag 或目標不同，導致你以為放行了，實際沒有套到。

7.2 金鑰輪替後只更新了一半

GCP帳號代充值 輪替金鑰時，常見只在本機換了 key，或只在某些 VM 更新。尤其當你有多台同系列 VM，某台還在舊 key，就會造成「某些能登、某些不能登」。

7.3 OS Login 與傳統 authorized_keys 機制混用

開啟 OS Login 後，很多人仍習慣手動寫 authorized_keys。結果兩套機制互相干擾或使你以為改了就會生效，卻其實登入是由另一套金鑰來源決定。

你可以選擇單一機制：要嘛以 OS Login 為準，要嘛關閉 OS Login 走傳統方式。混用通常會讓故障難以重現。

第八章：一個可落地的修復案例（以「先網路、再授權、最後 sshd」為順序）

以下是一個常見修復路徑，我用「你正在新加坡區的 Compute Engine 實例上遇到拒絕訪問」來串起來。你可以把它當成實操劇本。

8.1 觀察錯誤訊息

你執行 ssh 時得到類似：「Unable to connect… timed out」或「Permission denied (publickey)」。

若是 timed out：先不碰金鑰，先看防火牆與連線方式。

若是 publickey：網路通常已通，接著查 OS Login 或 authorized_keys 與權限。

8.2 若是 timed out：修防火牆

你回到 VPC 防火牆規則，確認：

規則方向 INGRESS

端口包含 22/TCP

target tag/service account 能對上實例

source IP ranges 包含你當下的來源 IP

修正後再嘗試連線。

常見修正是：把來源 IP 從過期的公司固定出口改成你當下真正出口的 CIDR，或把規則綁定的 target tag 加到實例上。

8.3 若是 publickey：確認 OS Login 或 authorized_keys

你查到 OS Login 開啟，且你帳號在 IAM 沒有相關權限。修復方式是給你的 Google 帳號授權，或使用正確方式把金鑰綁定到 OS Login。

如果你沒有 OS Login，則進入 VM（用替代方式，例如串連/救援）檢查：

~/.ssh 是否存在

authorized_keys 是否包含你的公鑰

權限與所有者是否正確

8.4 若仍失敗：檢查 sshd_config 與日誌

你查看 sshd 日誌，看到可能的訊息包括：

拒絕該用戶

金鑰被忽略（權限問題）

或設定禁止該登入方式

修復後重啟 sshd（或讓系統自動重載設定）。再測一次，直到成功。

第九章：避免再次發生——把 SSH 連線納入部署標準

排除一次問題不難，難的是讓同樣的錯誤不再出現。建議你把以下項目納入部署/變更流程：

1）防火牆規則使用最小必要原則：只放行必要來源與端口，且有明確規則命名。

2）實例建立時自動套用 network tags 或指定 service account，避免規則雖有卻不匹配。

3）統一 SSH 金鑰管理策略：要嘛全面 OS Login，要嘛全面 authorized_keys；不要混用。

4）變更金鑰時同步更新所有目標 VM，並保留回滾方式。

5）在手冊中記錄：你使用的是外部 IP、內網 IP、還是 IAP；你用哪個帳號與金鑰。

第十章：結語——拒絕訪問不是運氣，是可拆解的問題

「GCP 新加坡實例 SSH 連線失敗拒絕訪問」看似玄學，實際上每個拒絕都有落點：要嘛網路層被防火牆擋住，要嘛認證層因 OS Login/金鑰不匹配被拒，要嘛服務端設定或權限讓 authorized_keys 無法生效。

你只要遵循「先網路、再授權、最後 sshd」的順序，每一步都可對應具體證據，通常不到一小時就能定位原因並修復。更重要的是，把修復寫進部署標準，下一次就不必再靠猜測。