排解 SSH 錯誤

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

本文將說明使用 SSH 連線至虛擬機器 (VM) 執行個體時，可能會遇到的常見錯誤、解決錯誤的方法，以及診斷 SSH 連線失敗的方法。

SSH 疑難排解工具

您可以運用 SSH 疑難排解工具，判斷 SSH 連線失敗的原因。這項疑難排解工具會執行下列測試，確認 SSH 連線失敗的原因：

• 使用者權限測試：檢查您是否具備使用 SSH 連至 VM 的必要 IAM 權限。
• 網路連線測試：檢查 VM 是否已連線至網路。
• VM 執行個體狀態測試：檢查 VM 的 CPU 狀態，確認 VM 是否處於執行中狀態。
• 虛擬私有雲設定測試：檢查預設的 SSH 通訊埠。

執行疑難排解工具

您可以使用 Google Cloud 控制台或 Google Cloud CLI，檢查可能導致 SSH 連線失敗的網路問題和使用者權限錯誤。

gcloud compute ssh VM_NAME \
    --troubleshoot

查看結果

執行疑難排解工具後，請採取以下步驟：

1. 查看測試結果，瞭解 VM 的 SSH 連線失敗原因。
2. 執行工具提供的修復步驟，解決 SSH 連線問題。

3. 嘗試重新連線至 VM。

   如果連線失敗，請嘗試手動排解問題，方法如下：

   • 使用序列主控台偵錯
   • 確保 VM 正常啟動

常見的 SSH 錯誤

以下列舉使用 SSH 連線至 Compute Engine VM 時可能會遇到的常見錯誤。

透過瀏覽器建立 SSH 連線時發生錯誤

未授權錯誤 401

從 Google Cloud 控制台使用 瀏覽器中的 SSH 連線至 VM 時，可能會發生下列錯誤：

Unauthorized
Error 401

如果使用者隸屬於透過 Google Workspace 管理的機構，且 Workspace 政策中設有限制，禁止使用者存取瀏覽器中的 SSH 和 Google Cloud中的序列主控台，就會發生這個錯誤。

如要解決這個問題，請請 Google Workspace 管理員執行下列操作：

1. 確認 Google Cloud 已為貴機構啟用。

   如果 Google Cloud 已停用，請啟用並重新嘗試連線。

2. 確認已啟用無法個別控制的服務。

   如果這些服務已停用，請重新啟用並重試連線。

如果在 Google Workspace 中啟用 Google Cloud 設定後問題仍未解決，請執行下列操作：

1. 從啟動瀏覽器中的 SSH 連線開始，在 HTTP 封存格式 (HAR) 檔案中擷取網路流量。

2. 建立 Cloud Customer Care 案件並附加 HAR 檔案。

無法連線，重試中...

啟動 SSH 工作階段時，可能會發生下列錯誤：

Could not connect, retrying ...

如要解決這個問題，請按照下列步驟操作：

1. VM 啟動完成後，請重試連線。如果連線失敗，請執行下列指令，確認 VM 並未以緊急模式啟動：

   gcloud compute instances get-serial-port-output VM_NAME \
   | grep "emergency mode"
   

   如果 VM 以緊急模式啟動，請排解VM 啟動程序，找出啟動程序失敗的原因。

2. 在序列控制台中執行下列指令，確認 google-guest-agent.service 服務是否正在執行。

   systemctl status google-guest-agent.service
   

   如果服務已停用，請執行下列指令啟用並啟動服務：

   systemctl enable google-guest-agent.service
   systemctl start google-guest-agent.service
   

3. 確認已安裝並執行 Linux Google Agent 指令碼。詳情請參閱「判斷 Google 代理程式狀態」。如果尚未安裝 Linux Google 代理程式，請重新安裝。

4. 確認您具備連線至 VM 所需的角色。如果您的 VM 使用 OS 登入，請參閱「指派 OS 登入 IAM 角色」。如果 VM 未使用 OS 登入，您需要運算單元管理員角色或服務帳戶使用者角色 (如果 VM 已設為以服務帳戶形式執行)。您必須具備這些角色，才能更新執行個體或專案的 SSH 金鑰中繼資料。

5. 執行下列指令，確認防火牆規則允許 SSH 存取：

   gcloud compute firewall-rules list | grep "tcp:22"
   

6. 確認有通往網際網路 (或堡壘主機) 的預設路徑。詳情請參閱「檢查路徑」。

7. 請確認根磁碟區的磁碟空間並未用盡。詳情請參閱「排解磁碟已滿和磁碟調整大小的問題」。

8. 執行下列指令，確認 VM 記憶體並未用盡：

   gcloud compute instances get-serial-port-output instance-name \
   | grep "Out of memory: Kill process" - e "Kill process" -e "Memory cgroup out of memory" -e "oom"
   

   如果 VM 記憶體不足，請連線至序列控制台進行疑難排解。

Linux 錯誤

權限遭拒 (publickey)

連線至 VM 時，可能會發生下列錯誤：

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

這項錯誤可能有多種原因。以下是這項錯誤最常見的原因：

• 您使用儲存在中繼資料中的 SSH 金鑰，連線至已啟用 OS 登入功能的 VM。如果在專案中啟用 OS 登入功能，VM 就不會接受儲存在中繼資料中的 SSH 金鑰。如果不確定是否已啟用 OS 登入，請參閱「檢查 OS 登入是否已設定」一文。

  如要解決這個問題，請嘗試下列任一做法：

  • 使用 Google Cloud 控制台或 Google Cloud CLI 連線至 VM。詳情請參閱「連線至 VM」。
  • 將安全殼層金鑰新增至 OS 登入功能。詳情請參閱將金鑰新增至使用 OS 登入功能的 VM。
  • 停用 OS 登入功能。詳情請參閱「停用 OS 登入」。

• 您使用儲存在 OS 登入設定檔中的 SSH 金鑰，連線至未啟用 OS 登入的 VM。如果您停用 OS 登入功能，VM 就不會接受儲存在 OS 登入設定檔中的安全殼層金鑰組。如果不確定是否已啟用 OS 登入，請參閱「檢查 OS 登入是否已設定」。

  如要解決這個問題，請嘗試下列任一做法：

  • 使用 Google Cloud 控制台或 Google Cloud CLI 連線至 VM。詳情請參閱「連線至 VM」。
  • 啟用 OS 登入功能。詳情請參閱「啟用 OS 登入」。
  • 將安全殼層金鑰新增至中繼資料。詳情請參閱在使用中繼資料為主的安全殼層金鑰 VM 中新增安全殼層金鑰。

• VM 已啟用 OS 登入，但您沒有足夠的 IAM 權限來使用 OS 登入。如要連線至已啟用 OS 登入功能的 VM，您必須具備 OS 登入功能所需的權限。如果不確定是否已啟用 OS 登入，請參閱「檢查 OS 登入是否已設定」一文。

  如要解決這個問題，請授予必要的 OS Login IAM 角色。

• 您的金鑰已過期，Compute Engine 已刪除您的 ~/.ssh/authorized_keys 檔案。如果您手動將 SSH 金鑰新增至 VM，然後使用 Google Cloud 主控台連線至 VM，Compute Engine 會為您的連線建立新的金鑰組。新金鑰組到期後，Compute Engine 會刪除 VM 中的 ~/.ssh/authorized_keys 檔案，其中包含您手動新增的安全殼層金鑰。

  如要解決這個問題，請嘗試下列任一做法：

  • 使用 Google Cloud 控制台或 Google Cloud CLI 連線至 VM。詳情請參閱「連線至 VM」。
  • 將安全殼層金鑰重新加入中繼資料。詳情請參閱在使用中繼資料為主的安全殼層金鑰 VM 中新增安全殼層金鑰。

• 您使用第三方工具連線，且 SSH 指令設定錯誤。如果您使用 ssh 指令連線，但未指定私密金鑰路徑，或指定的私密金鑰路徑不正確，VM 就會拒絕您的連線。

  如要解決這個問題，請嘗試下列任一做法：

  • 執行下列指令：
    

    ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP
    

    
    請依指示取代下列內容：
    • PATH_TO_PRIVATE_KEY：私密安全殼層金鑰檔案的路徑。
    • USERNAME：連線至執行個體的使用者名稱。如果您在中繼資料中管理安全殼層金鑰，則使用者名稱就是您建立安全殼層金鑰時指定的名稱。對於 OS 登入帳戶，使用者名稱會在 Google 個人資料中定義。
    • EXTERNAL_IP：VM 的外部 IP 位址。
  • 使用 Google Cloud 控制台或 Google Cloud CLI 連線至 VM。當您使用這些工具連線時，Compute Engine 會為您管理金鑰建立作業。詳情請參閱「連線至 VM」。

• VM 的訪客環境未執行。如果這是您第一次連線至 VM，且未執行訪客環境，VM 可能會拒絕您的 SSH 連線要求。

  如要解決這個問題，請按照下列步驟操作：

  1. 重新啟動 VM。
  2. 在 Google Cloud 控制台中，檢查序列埠輸出內容中的系統啟動記錄，判斷訪客環境是否正在執行。詳情請參閱「驗證訪客環境」。
  3. 如果訪客環境未執行，請複製 VM 的開機磁碟並使用啟動指令碼，手動安裝訪客環境。

• OpenSSH Daemon (sshd) 未正確設定或未執行。sshd 可透過 SSH 通訊協定，安全地從遠端存取系統。如果設定錯誤或未執行，您就無法透過 SSH 連線至 VM。

  如要解決這個問題，請嘗試下列一或多個方法：

  • 請參閱您作業系統適用的使用手冊，確保已正確設定 sshd_config。

  • 請確認您已設定下列項目的必要擁有權和權限：

    • $HOME 和 $HOME/.ssh 目錄
    • $HOME/.ssh/authorized_keys 檔案

    擁有權

    訪客環境會將授權的安全殼層公開金鑰儲存在 $HOME/.ssh/authorized_keys 檔案中。$HOME 和 $HOME/.ssh 目錄和 $HOME/.ssh/authorized_keys 檔案的擁有者，必須與連線至 VM 的使用者相同。

    權限

    訪客環境需要下列 Linux 權限：

    路徑	權限
    /home	0755
    $HOME	0700 或 0750 或 0755 *
    $HOME/.ssh	0700
    $HOME/.ssh/authorized_keys	0600

    ^* 如要瞭解哪些選項是 $HOME 目錄的正確預設權限，請參閱特定 Linux 發行版的官方文件。

    ---

    或者，您也可以根據相同的映像檔建立新的 VM，並檢查其 $HOME 的預設權限。

    如要瞭解如何變更權限和擁有權，請參閱 chmod 和 chown。

  • 執行下列指令，重新啟動 sshd：

    systemctl restart sshd.service

    執行下列指令，檢查狀態是否有任何錯誤：

    systemctl status sshd.service

    狀態輸出內容可能包含退出代碼、失敗原因等資訊。您可以利用這些詳細資料進一步排解問題。

• VM 的開機磁碟已滿。建立 SSH 連線後，訪客環境會將工作階段的公開安全殼層 (SSH) 金鑰加入 ~/.ssh/authorized_keys 檔案。如果磁碟已滿，連線就會失敗。

  如要解決這個問題，請執行下列一或多項操作：

  • 使用序列主控台進行偵錯，找出 no space left errors，確認開機磁碟已滿。
  • 調整磁碟大小。
  • 如果您知道哪些檔案佔用了磁碟空間，請建立開機指令碼刪除不必要的檔案，藉此釋出空間。VM 啟動並連線後，請刪除 startup-script 中繼資料。

• 對於 $HOME、$HOME/.ssh 或 $HOME/.ssh/authorized_keys 的權限或擁有權有誤。

  擁有權

  訪客環境會將授權的安全殼層公開金鑰儲存在 $HOME/.ssh/authorized_keys 檔案中。$HOME 和 $HOME/.ssh 目錄和 $HOME/.ssh/authorized_keys 檔案的擁有者，必須與連線至 VM 的使用者相同。

  權限

  訪客環境需要下列 Linux 權限：

  路徑	權限
  /home	0755
  $HOME	0700 或 0750 或 0755 *
  $HOME/.ssh	0700
  $HOME/.ssh/authorized_keys	0600

  ^* 如要瞭解哪些選項是 $HOME 目錄的正確預設權限，請參閱特定 Linux 發行版的官方文件。

  ---

  或者，您也可以根據相同的映像檔建立新的 VM，並檢查其 $HOME 的預設權限。

  如要瞭解如何變更權限和擁有權，請參閱 chmod 和 chown。

無法連線

透過 Google Cloud 控制台、gcloud CLI、防禦主機或本機用戶端連線至 VM 時，可能會發生下列錯誤：

• Google Cloud 控制台：

  Connection Failed
  
  We are unable to connect to the VM on port 22.
  

• gcloud CLI：

  ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
  

• 防禦主機或本機用戶端：

  port 22: Connection timed out.
  

  port 22: Connection refused
  

造成這些錯誤的原因有很多。以下是導致錯誤的幾個最常見原因：

• VM 正在啟動，sshd 尚未執行。您無法在 VM 執行前連線。

  如要解決這個問題，請等待 VM 啟動完畢，然後再試著重新連線。

• sshd 會在自訂通訊埠上執行。如果您將 sshd 設為在 22 以外的通訊埠上執行，就無法連線至 VM。

  如要解決這個問題，請使用下列指令，在 sshd 執行的通訊埠上建立自訂防火牆規則，允許 tcp 流量：

  gcloud compute firewall-rules create FIREWALL_NAME \
    --allow tcp:PORT_NUMBER
  

  如要進一步瞭解如何建立自訂防火牆規則，請參閱「建立防火牆規則」。

• SSH 防火牆規則遺漏或不允許來自 IAP 或公開網際網路的流量。如果防火牆規則不允許 IP 範圍 0.0.0.0/0 的 IAP 或 TCP 輸入流量連線，系統就會拒絕 SSH 連線。

  如要解決這個問題，請按照下列任一做法進行：

  • 如果您使用 Identity-Aware Proxy (IAP) 進行 TCP 轉送，請更新自訂防火牆規則，接受來自 IAP 的流量，然後檢查 IAM 權限。

    1. 請更新自訂防火牆規則，允許來自 35.235.240.0/20 的流量，這是 IAP 用於 TCP 轉送的 IP 位址範圍。詳情請參閱「建立防火牆規則」。
    2. 如果尚未授予 IAP TCP 轉送功能的使用權限，請授予權限。

  • 如果您未使用 IAP，請更新自訂防火牆規則，允許 SSH 流量進入。

    1. 更新自訂防火牆規則，允許 VM 的入站 SSH 連線。

• 升級 VM 的核心後，SSH 連線失敗。在核心更新後，VM 可能會發生核心異常中止的情形，導致無法存取 VM。

  如要解決這個問題，請按照下列步驟操作：

  1. 將磁碟掛接至另一個 VM。
  2. 更新 grub.cfg 檔案，以便使用舊版核心。
  3. 將磁碟連結至無法回應的 VM。
  4. 使用 gcloud compute instances describe 指令，確認 VM 的狀態為 RUNNING。
  5. 重新安裝核心。
  6. 重新啟動 VM。

  或者，如果您在升級 VM 前建立了開機磁碟快照，請使用快照建立 VM。

• OpenSSH Daemon (sshd) 未正確設定或未執行。sshd 可透過 SSH 通訊協定，安全地從遠端存取系統。如果設定錯誤或未執行，您就無法透過 SSH 連線至 VM。

  如要解決這個問題，請嘗試下列一或多個方法：

  • 請參閱您作業系統適用的使用手冊，確保已正確設定 sshd_config。

  • 請確認您已設定下列項目的必要擁有權和權限：

    • $HOME 和 $HOME/.ssh 目錄
    • $HOME/.ssh/authorized_keys 檔案

    擁有權

    訪客環境會將授權的安全殼層公開金鑰儲存在 $HOME/.ssh/authorized_keys 檔案中。$HOME 和 $HOME/.ssh 目錄和 $HOME/.ssh/authorized_keys 檔案的擁有者，必須與連線至 VM 的使用者相同。

    權限

    訪客環境需要下列 Linux 權限：

    路徑	權限
    /home	0755
    $HOME	0700 或 0750 或 0755 *
    $HOME/.ssh	0700
    $HOME/.ssh/authorized_keys	0600

    ^* 如要瞭解哪些選項是 $HOME 目錄的正確預設權限，請參閱特定 Linux 發行版的官方文件。

    ---

    或者，您也可以根據相同的映像檔建立新的 VM，並檢查其 $HOME 的預設權限。

    如要瞭解如何變更權限和擁有權，請參閱 chmod 和 chown。

  • 執行下列指令，重新啟動 sshd：

    systemctl restart sshd.service

    執行下列指令，檢查狀態是否有任何錯誤：

    systemctl status sshd.service

    狀態輸出內容可能包含退出代碼、失敗原因等資訊。您可以利用這些詳細資料進一步排解問題。

• VM 無法啟動，您無法使用 SSH 或序列主控台連線。如果無法存取 VM，則作業系統可能已損毀。如果無法啟動啟動磁碟，您可以診斷問題。如要復原毀損的 VM 並擷取資料，請參閱「復原毀損的 VM 或整個開機磁碟」。

• VM 會以維護模式啟動。在維護模式下啟動時，VM 不會接受 SSH 連線，但您可以連線至 VM 的序列主控台，並以超級使用者身分登入。

  如要解決這個問題，請按照下列步驟操作：

  1. 如果您尚未為 VM 設定根密碼，請使用中繼資料開機指令碼，在啟動期間執行下列指令：

     echo 'root:NEW_PASSWORD' | chpasswd

     將 NEW_PASSWORD 替換為您選擇的密碼。

  2. 重新啟動 VM。

  3. 連線至 VM 的序列主控台，並以超級使用者身分登入。

非預期的錯誤

嘗試連線至 Linux VM 時，可能會發生下列錯誤：

Connection Failed
You cannot connect to the VM instance because of an unexpected error. Wait a few moments and then try again.

這項問題可能有多種原因。以下是導致錯誤發生的常見原因：

• OpenSSH Daemon (sshd) 未正確設定或未執行。sshd 可透過 SSH 通訊協定，安全地從遠端存取系統。如果設定錯誤或未執行，您就無法透過 SSH 連線至 VM。

  如要解決這個問題，請嘗試下列一或多個方法：

  • 請參閱您作業系統適用的使用手冊，確保已正確設定 sshd_config。

  • 請確認您已設定下列項目的必要擁有權和權限：

    • $HOME 和 $HOME/.ssh 目錄
    • $HOME/.ssh/authorized_keys 檔案

    擁有權

    訪客環境會將授權的安全殼層公開金鑰儲存在 $HOME/.ssh/authorized_keys 檔案中。$HOME 和 $HOME/.ssh 目錄和 $HOME/.ssh/authorized_keys 檔案的擁有者，必須與連線至 VM 的使用者相同。

    權限

    訪客環境需要下列 Linux 權限：

    路徑	權限
    /home	0755
    $HOME	0700 或 0750 或 0755 *
    $HOME/.ssh	0700
    $HOME/.ssh/authorized_keys	0600

    ^* 如要瞭解哪些選項是 $HOME 目錄的正確預設權限，請參閱特定 Linux 發行版的官方文件。

    ---

    或者，您也可以根據相同的映像檔建立新的 VM，並檢查其 $HOME 的預設權限。

    如要瞭解如何變更權限和擁有權，請參閱 chmod 和 chown。

  • 執行下列指令，重新啟動 sshd：

    systemctl restart sshd.service

    執行下列指令，檢查狀態是否有任何錯誤：

    systemctl status sshd.service

    狀態輸出內容可能包含退出代碼、失敗原因等資訊。您可以利用這些詳細資料進一步排解問題。

• 不明的 SSH 守護程式問題。如要診斷不明的 SSH 守護程式問題，請檢查 序列控制台記錄是否有錯誤。

  根據序列控制台記錄檔的輸出內容，請嘗試救援 VM，並按照下列步驟修正 SSH 守護程序相關問題：

  1. 將磁碟連接至另一個 Linux VM。
  2. 連線至已掛接磁碟的 VM。
  3. 將 OS 中的磁碟掛接至 VM 內的目錄 MOUNT_DIR。
  4. 查看 SSH 相關記錄檔 (/var/log/secure 或 /var/log/auth.log)，瞭解是否有任何問題/錯誤。如果發現任何可修正的問題，請嘗試修正。否則請建立支援案件並附上記錄。

  5. 使用 umount 指令從 OS 卸載磁碟：

     cd ~/
     umount /mnt
     

  6. 從 VM 卸離磁碟。

  7. 將磁碟連接至原始 VM。

  8. 啟動 VM。

無法連線至後端

透過 Google Cloud 控制台或 gcloud CLI 連線至 VM 時，可能會發生下列錯誤：

• Google Cloud 控制台：

  -- Connection via Cloud Identity-Aware Proxy Failed
  
  -- Code: 4003
  
  -- Reason: failed to connect to backend
  

• gcloud CLI：

  ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: 'failed to connect to backend'].
  

當您嘗試使用 SSH 連線至沒有公開 IP 位址的 VM，且未在 22 埠上設定 Identity-Aware Proxy 時，就會發生這些錯誤。

如要解決這個問題，請在通訊埠 22 上建立防火牆規則，允許來自 Identity-Aware Proxy 的輸入流量。

主機金鑰不相符

連線至 VM 時，可能會發生下列錯誤：

Host key for server IP_ADDRESS does not match

如果 ~/.ssh/known_hosts 檔案中的主機金鑰與 VM 的主機金鑰不符，就會發生這項錯誤。

如要解決這個問題，請從 ~/.ssh/known_hosts 檔案中刪除主機金鑰，然後重試連線。

中繼資料值過大

嘗試將新的 SSH 金鑰新增至中繼資料時，可能會發生下列錯誤：

ERROR:"Value for field 'metadata.items[X].value' is too large: maximum size 262144 character(s); actual size NUMBER_OF_CHARACTERS."

中繼資料值的大小上限為 256 KB。如要克服這項限制，請採取下列任一做法：

• 從專案或執行個體中繼資料中刪除已過期或重複的 SSH 金鑰。詳情請參閱「在執行中的 VM 上更新中繼資料」。
• 使用 OS 登入。

Windows 錯誤

權限遭拒，請再試一次

連線至 VM 時，可能會發生下列錯誤：

USERNAME@compute.INSTANCE_ID's password:
Permission denied, please try again.

這個錯誤表示嘗試連線至 VM 的使用者不存在於 VM 中。以下是導致這項錯誤的常見原因：

• 您的 gcloud CLI 版本過舊

  如果 gcloud CLI 版本過舊，您可能會嘗試使用未設定的使用者名稱進行連線。如要解決這個問題，請更新 gcloud CLI。

• 您嘗試連線至未啟用 SSH 的 Windows VM。

  如要解決這項錯誤，請在專案或執行個體中繼資料中，將 enable-windows-ssh 鍵設為 TRUE。如要進一步瞭解如何設定中繼資料，請參閱「設定自訂中繼資料」。

權限遭拒 (publickey,keyboard-interactive)

連線至未啟用 SSH 的 VM 時，可能會發生下列錯誤：

Permission denied (publickey,keyboard-interactive).

如要解決這項錯誤，請在專案或執行個體中繼資料中，將 enable-windows-ssh 鍵設為 TRUE。如要進一步瞭解如何設定中繼資料，請參閱「設定自訂中繼資料」。

無法透過 SSH 連線至執行個體

從 gcloud CLI 連線至 VM 時，可能會發生下列錯誤：

ERROR: (gcloud.compute.ssh) Could not SSH into the instance.
It is possible that your SSH key has not propagated to the instance yet.
Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.

這項錯誤可能有多種原因。以下是導致錯誤的幾個最常見原因：

• 您嘗試連線至未安裝 SSH 的 Windows VM。

  如要解決這個問題，請按照在執行中的 VM 上啟用 Windows 版 SSH的操作說明操作。

• OpenSSH 伺服器 (sshd) 未執行或設定不正確。sshd 可透過 SSH 通訊協定，安全地從遠端存取系統。如果設定錯誤或未執行，您就無法透過 SSH 連線至 VM。

  如要解決這個問題，請參閱「Windows Server 和 Windows 的 OpenSSH Server 設定」，確保 sshd 已正確設定。

連線逾時

SSH 連線逾時可能由下列其中一個原因造成：

• VM 尚未完成啟動。等待 VM 開機。

  如要解決這個問題，請等待 VM 啟動完畢，然後再試著重新連線。

• 未安裝 SSH 套件。您必須先安裝 google-compute-engine-ssh 套件，才能使用 SSH 連線至 Windows VM。

  如要解決這個問題，請安裝 SSH 套件。

診斷 SSH 連線失敗的原因

以下各節將說明如何診斷 SSH 連線失敗的原因，以及如何修正連線問題。

請先完成下列步驟，再診斷 SSH 連線失敗的原因：

• 安裝或更新至最新版 Google Cloud CLI。
• 執行連線能力測試。
• 如果您使用的是未執行訪客環境的自訂 Linux 映像檔，請安裝 Linux 訪客環境。
• 如果您使用 OS 登入，請參閱「OS 登入疑難排解」。

Linux 和 Windows VM 的診斷方法

測試連線能力

您有可能因為防火牆、網路連線或使用者帳戶相關的連線問題，而無法透過安全殼層連線至 VM 執行個體。請按照本節中的步驟判斷是否有連線問題。

檢查您的防火牆規則

Compute Engine 會為每個專案佈建一組預設的防火牆規則，該規則允許 SSH 流量。如果您無法存取執行個體，請使用 gcloud compute 指令列工具檢查防火牆清單，確認 default-allow-ssh 規則是否存在。

在本機工作站上，執行下列指令：

gcloud compute firewall-rules list

如果找不到該防火牆規則，請將該規則加回去：

gcloud compute firewall-rules create default-allow-ssh \
    --allow tcp:22

如要查看專案中與 default-allow-ssh 防火牆規則相關聯的所有資料，請使用 gcloud compute firewall-rules describe 指令：

gcloud compute firewall-rules describe default-allow-ssh \
    --project=project-id

如要進一步瞭解防火牆規則，請參閱「 Google Cloud中的防火牆規則」。

測試網路連線

如要判斷網路連線是否正常運作，請測試 TCP 握手：

1. 取得 VM 的外部 natIP：

   gcloud compute instances describe VM_NAME \
       --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
   

   將 VM_NAME 替換為您無法連線的 VM 名稱。

2. 從工作站測試與 VM 的網路連線：

   Linux、Windows 2019/2022 和 macOS

   curl -vso /dev/null --connect-timeout 5 EXTERNAL_IP:PORT_NUMBER
   

   更改下列內容：

   • EXTERNAL_IP：您在上一個步驟中取得的外部 IP 位址
   • PORT_NUMBER：通訊埠編號

   如果 TCP 握手成功，輸出內容會與下列內容相似：

   Expire in 0 ms for 6 (transfer 0x558b3289ffb0)
   Expire in 5000 ms for 2 (transfer 0x558b3289ffb0)
   Trying 192.168.0.4...
   TCP_NODELAY set
   Expire in 200 ms for 4 (transfer 0x558b3289ffb0)
   Connected to 192.168.0.4 (192.168.0.4) port 443 (#0)
   > GET / HTTP/1.1
   > Host: 192.168.0.4:443
   > User-Agent: curl/7.64.0
   > Accept: */*
   >
   Empty reply from server
   Connection #0 to host 192.168.0.4 left intact
   

   Connected to 行表示 TCP 握手成功。

   Windows 2012 和 2016

   PS C:> New-Object System.Net.Sockets.TcpClient('EXTERNAL_IP',PORT_NUMBER)
   

   更改下列內容：

   • EXTERNAL_IP：您在上一個步驟中取得的外部 IP
   • PORT_NUMBER：通訊埠編號

   如果 TCP 握手成功，輸出內容會與下列內容相似：

   Available           : 0
   Client              : System.Net.Sockets.Socket
   Connected           : True
   ExclusiveAddressUse : False
   ReceiveBufferSize   : 131072
   SendBufferSize      : 131072
   ReceiveTimeout      : 0
   SendTimeout         : 0
   LingerState         : System.Net.Sockets.LingerOption
   NoDelay             : False
   

   Connected: True 行表示 TCP 握手成功。

如果 TCP 握手完成，軟體防火牆規則不會封鎖連線，作業系統會正確轉送封包，且伺服器會在目的地通訊埠上聆聽。如果 TCP 握手成功完成，但 VM 不接受 SSH 連線，問題可能出在 sshd 守護程式設定錯誤或無法正常執行。請參閱您作業系統適用的使用手冊，確保已正確設定 sshd_config。

如要執行連線測試，以便分析兩個 VM 之間的 VPC 網路路徑設定，並檢查程式設計的設定是否應允許流量，請參閱「檢查 Google Cloud 中設定錯誤的防火牆規則」。

以其他使用者身分連線

阻止您登入的問題可能出在您使用者帳戶內的設定。例如，沒有為使用者正確設定執行個體上 ~/.ssh/authorized_keys 檔案的權限。

請嘗試使用 gcloud CLI 以不同的使用者身分登入，方法是透過 SSH 要求指定 ANOTHER_USERNAME。gcloud CLI 會更新專案的中繼資料，以加入新使用者並允許 SSH 存取權。

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

更改下列內容：

• ANOTHER_USERNAME 是您自己的使用者名稱以外的使用者名稱
• VM_NAME 是您要連線的 VM 名稱

使用序列主控台偵錯

建議您檢查序列控制台中的記錄，找出連線錯誤。您可以使用瀏覽器，從本機工作站以根使用者的身分存取序列主控台。當您無法透過安全殼層登入，或執行個體未連線至網路時，這個方法會特別實用。在這兩種情況下，序列主控台仍會保持可存取的狀態。

如要登入 VM 的序列控制台，並排除 VM 問題，請按照下列步驟操作：

1. 啟用虛擬機器序列主控台的互動存取權。

2. 針對 Linux VM，請修改根密碼，並將下列開機指令碼新增至 VM：

   echo root:PASSWORD | chpasswd

   將 PASSWORD 替換為您選擇的密碼。

3. 使用序列主控台連線至 VM。

4. 針對 Linux VM，在完成所有錯誤的偵錯作業後，請停用根帳戶登入功能：

   sudo passwd -l root

Linux VM 的診斷方法

檢查但不關閉 VM 執行個體

您可能無法連線至某個執行個體，但該執行個體會繼續正常地提供實際工作環境流量。在這種情況下，您可能會希望在不中斷執行個體的情況下檢查磁碟。

如要檢查磁碟並排解問題，請按照下列步驟操作：

1. 建立磁碟快照來備份開機磁碟。
2. 從該快照建立一般永久磁碟。
3. 建立臨時執行個體。
4. 將一般永久磁碟連結並掛接至新的暫時執行個體。

這個程序會建立僅允許 SSH 連線的獨立網路。如此設定可避免複製的執行個體干擾正式服務而造成非預期的結果。

1. 建立託管複製執行個體的新虛擬私人雲端網路：

   gcloud compute networks create debug-network
   

   將 NETWORK_NAME 替換為您要命名的新網路。

2. 新增防火牆規則以允許網路接受 SSH 連線：

   gcloud compute firewall-rules create debug-network-allow-ssh \
      --network debug-network \
      --allow tcp:22
   

3. 建立開機磁碟的快照。

   gcloud compute disks snapshot BOOT_DISK_NAME \
      --snapshot-names debug-disk-snapshot
   

   請將 BOOT_DISK_NAME 替換為開機磁碟的名稱。

4. 透過剛建立的快照建立新磁碟：

   gcloud compute disks create example-disk-debugging \
      --source-snapshot debug-disk-snapshot
   

5. 建立沒有外部 IP 位址的新除錯執行個體：

   gcloud compute instances create debugger \
      --network debug-network \
      --no-address
   

6. 將除錯磁碟連結至執行個體：

   gcloud compute instances attach-disk debugger \
      --disk example-disk-debugging
   

7. 請按照這篇文章的操作說明，使用防禦主機連線至 VM。

8. 登入偵錯工具執行個體後，對執行個體進行疑難排解。舉例來說，您可以查看執行個體記錄檔：

   sudo su -
   

   mkdir /mnt/VM_NAME
   

   mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/VM_NAME
   

   cd /mnt/VM_NAME/var/log
   

   # Identify the issue preventing ssh from working
   ls
   

   將 VM_NAME 替換為您無法連線的 VM 名稱。

使用開機指令碼

如果上述方法都沒能解決問題，您可以建立開機指令碼，以便在執行個體啟動後立即收集資訊。請按照執行開機指令碼中的指示操作。

接著，您必須使用 gcloud compute instances reset，在中繼資料生效前重設執行個體。

此外，您也可以使用診斷開機指令碼重新建立執行個體：

1. 使用 --keep-disks 旗標執行 gcloud compute instances delete。

   gcloud compute instances delete VM_NAME \
      --keep-disks boot
   

   將 VM_NAME 替換為您無法連線的 VM 名稱。

2. 新增具有相同磁碟的新執行個體並指定開機指令碼。

   gcloud compute instances create NEW_VM_NAME \
      --disk name=BOOT_DISK_NAME,boot=yes \
      --metadata startup-script-url URL
   

   更改下列內容：

   • NEW_VM_NAME 是您要建立的新 VM 名稱
   • BOOT_DISK_NAME 是您無法連線的 VM 開機磁碟名稱
   • URL 是指令碼的 Cloud Storage 網址，格式為 gs://BUCKET/FILE 或 https://storage.googleapis.com/BUCKET/FILE。

在新的執行個體上使用磁碟

如果您仍需要從永久開機磁碟復原資料，請卸除開機磁碟，然後將該磁碟做為次要磁碟附加至新的執行個體上。

1. 刪除無法連線的 VM，並保留其啟動磁碟：

   gcloud compute instances delete VM_NAME \
      --keep-disks=boot 

   將 VM_NAME 替換為您無法連線的 VM 名稱。

2. 使用舊 VM 的開機磁碟建立新 VM。指定剛剛刪除的 VM 開機磁碟名稱。

3. 使用 SSH 連線至新的 VM：

   gcloud compute ssh NEW_VM_NAME
   

   將 NEW_VM_NAME 替換為新的 VM 名稱。

檢查 VM 開機磁碟是否已滿

如果開機磁碟已滿，可能無法存取 VM。這種情況可能很難排解，因為 VM 連線問題是否是因為開機磁碟已滿，不一定很明顯。如要進一步瞭解這種情況，請參閱「排解因啟動磁碟空間不足而無法存取的 VM 問題」。

Windows VM 的診斷方法

重設 SSH 中繼資料

如果您無法使用 SSH 連線至 Windows VM，請嘗試取消設定 enable-windows-ssh 中繼資料鍵，然後重新啟用 Windows 的 SSH。

1. 將 enable-windows-ssh 中繼資料鍵設為 FALSE。如要瞭解如何設定中繼資料，請參閱「設定自訂中繼資料」。

   請稍候幾秒鐘，等待變更生效。

2. 重新啟用 Windows 的 SSH

3. 重新連線至 VM。

使用遠端桌面協定連線至 VM

如果您無法診斷及解決 SSH 連線至 Windows VM 失敗的原因，請使用 RDP 連線。

建立 VM 連線後，請查看 OpenSSH 記錄。

後續步驟

• 瞭解如何透過 SSH 連線至 Linux VM，在 Compute Engine 上執行工作負載。