排解 SSH 錯誤

Linux Windows

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

SSH 疑難排解工具

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

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

執行疑難排解工具

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

這項工作需要的權限

如要執行這項工作，您必須具備下列權限：

• VM 上的 networkmanagement.connectivitytests.create
• VM 上的 networkmanagement.connectivitytests.delete
• VM 上的 networkmanagement.connectivitytests.get

如果缺少上述任何權限，疑難排解工具會略過網路連線測試。

控制台

SSH 連線失敗後，您可以選擇「Retry」(重試) 連線，或使用瀏覽器內建 SSH 疑難排解工具「Troubleshoot」(疑難排解) 連線。

如要執行疑難排解工具，請按一下「Troubleshoot」(疑難排解)。

gcloud

使用 gcloud compute ssh 指令執行疑難排解工具：

gcloud compute ssh VM_NAME --troubleshoot [--tunnel-through-iap]

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

如果您要排解透過 Identity-Aware Proxy 轉送 TCP 的連線問題，請使用 --tunnel-through-iap 旗標。

工具會提示您授予權限，以便執行疑難排解測試。

查看結果

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

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

3. 嘗試重新連線至 VM。

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

   • 使用序列控制台偵錯
   • 確認 VM 正常啟動

常見的 SSH 錯誤

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

SSH-in-Browser 錯誤

未授權錯誤 401

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

Unauthorized
Error 401

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

如要解決這個問題，請要求 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 代理程式指令碼已安裝並執行。詳情請參閱「判斷 Google 代理程式狀態」。如果未安裝 Linux Google 代理程式，請重新安裝。

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

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 錯誤

Permission denied (publickey)

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

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

發生這個錯誤的原因有很多，以下是造成這項錯誤的一些最常見原因：

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

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

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

• 您使用儲存在 OS 登入設定檔中的安全殼層金鑰，連線至未啟用 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 登入 IAM 角色。

• 您使用非 Google 管理的本機帳戶，連線至已啟用 OS 登入功能的 VM。OS 登入會使用 IAM 角色驗證使用者，因此會拒絕未與 Google Identity 和必要權限建立關聯的本機帳戶存取。

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

  • 使用具備必要 OS 登入 IAM 角色的 IAM 使用者，連線至 VM。

  • 使用中繼資料開機指令碼，為本機使用者設定安全殼層金鑰：

    1. 前往 Google Cloud 控制台的「VM instances」(VM 執行個體) 頁面。
    2. 按一下要設定本機使用者的 VM 名稱。
    3. 按一下 [編輯]。
    4. 在「中繼資料」下方，點選「新增項目」。
    5. 在「Key」(鍵) 部分輸入 startup-script。
    6. 在「值」部分，輸入類似下方的指令碼，建立使用者並新增公開安全殼層金鑰：

    #!/bin/bash
    # Create the local user if it doesn't exist
    if ! id -u <var>USERNAME</var> >/dev/null 2>&1; then
      useradd -m -s /bin/bash <var>USERNAME</var>
    fi
    
    # Create the SSH directory and authorized_keys file
    mkdir -p /home/<var>USERNAME</var>/.ssh
    echo "<var>SSH_KEY</var>" >> /home/>varUSERNAME/var&>lt;/.ssh/authorized_keys
    
    # Set permissions and ownership
    chmod 700 /home/varU<SER>NAME/var</.ss>h
    chmod 600 /home/varU<SER>NAME/var</.ss>h/authorized_keys
    chown -R varU<SER>NAME/var<:var>U<SER>NAME/var< /home/varU<SER>NAME/var</.ss>h
    

    更改下列內容：

    • USERNAME：要建立或設定的本機使用者名稱。
    • SSH_KEY：您的公開安全殼層金鑰。
    1. 按一下「Save」(儲存)，然後重新啟動 VM。

  • 停用 OS 登入功能。詳情請參閱「停用 OS 登入」。

• 金鑰已過期，Compute Engine 已刪除您的 ~/.ssh/authorized_keys 檔案。如果您手動將安全殼層金鑰新增至 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 的問題，您必須以超級使用者身分連線至 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/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
  

注意： 發生任何連線或驗證錯誤時，ssh 用戶端都會傳回結束代碼 255，因此單憑 gcloud CLI 錯誤無法找出特定原因。當 VM 關閉使用中的工作階段時 (例如從工作階段中重新啟動 VM)，ssh 用戶端也會傳回這個結束代碼。如果只有在工作階段中重新啟動或關閉 VM 後，才會出現錯誤，則可忽略。

如要查看基礎 ssh 錯誤 (例如連線逾時、連線遭拒或 Permission denied (publickey))，請執行 gcloud compute ssh 指令，並使用詳細的 ssh 輸出內容：

gcloud compute ssh VM_NAME --ssh-flag="-vvv"

將 VM_NAME 替換為 VM 名稱。

您也可以執行 SSH 疑難排解工具，檢查連線失敗的常見原因。

發生這類錯誤的原因有很多，以下是幾個最常見的錯誤原因：

• VM 正在啟動，sshd 尚未執行。VM 必須處於執行中狀態，才能連線。

  如要解決這個問題，請等到 VM 啟動完畢，再嘗試重新連線。

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

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

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

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

• 缺少 SSH 防火牆規則，或不允許來自 IAP 或公開網際網路的流量。如果防火牆規則不允許來自 IAP 的連線，或 IP 範圍 0.0.0.0/0 的 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 可能會在核心更新後發生核心錯誤，導致無法存取。

  請按照下列步驟解決這個問題：

  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 的問題，您必須以超級使用者身分連線至 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，表示 OS 可能已損毀。如果開機磁碟無法啟動，您可以診斷問題。如要復原損毀的 VM 並擷取資料，請參閱「復原損毀的 VM 或已滿的開機磁碟」。

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

  請按照下列步驟解決這個問題：

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

     echo 'root:NEW_PASSWORD' | chpasswd

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

  2. 重新啟動 VM。

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

• SSH 工作階段在大約 30 秒後凍結或中斷連線。這個問題通常是因為 OS 層級防火牆規則捨棄已建立的連線，或最大傳輸單位 (MTU) 不符，導致傳輸資料時封包遭到捨棄。

  如要解決這個問題，請執行下列一或多項疑難排解步驟：

  • 檢查訪客 OS 防火牆：檢查訪客 OS 防火牆規則，確保規則不會限制頻率、捨棄有狀態連線，或封鎖 SSH 流量。

    • 使用序列控制台連線至 VM，然後執行 sudo iptables -S (或 sudo ufw status) 來檢查有效規則。
    • 如要測試使用中的規則是否會封鎖流量，請執行 sudo iptables -F 或 sudo ufw disable 等指令，暫時停用或清除這些規則。

  • 驗證 MTU 設定：如果虛擬私有雲網路和客體 OS 的 MTU 不一致，網路可能會在不通知的情況下捨棄大型封包 (例如執行會產生大量輸出的指令，像是 cat 或 top)。

    • 請參閱「變更虛擬私有雲網路的 MTU」，確認虛擬私有雲網路 MTU 設定 (預設為 1460)。
    • 在執行個體上執行 ip link show，找出使用中的介面名稱 (例如 ens4 或 eth0)，並驗證其 mtu 值。
    • 執行連線偵測 (ping) 測試，並設定「不分段」(DF) 位元：ping -M do -s 1432 TARGET_IP (其中 1432 位元組的酬載大小加上 28 個 ICMP/IP 標頭位元組，等於標準 1460 MTU)。如果輸出內容類似 Message too long, mtu = ...，表示 MTU 不相符。
    • 暫時調整 OS 介面 MTU，使其與虛擬私有雲網路相符：sudo ip link set dev INTERFACE_NAME mtu VPC_MTU。
    • 如果使用 Cloud Interconnect 或 VPN，請確認所有地端部署路由器、傳輸閘道和虛擬私有雲網路的 MTU 設定一致。

• 無法從快照/複製項目透過 SSH 連線至 VM。從快照或複製的磁碟建立 VM 時，磁碟上快取的靜態網路設定可能會與新 VM 的 MAC 位址衝突，導致網路介面無法初始化，並封鎖 SSH 存取。

  如要解決這個問題，請使用序列控制台連線至 VM，並更新網路設定，使其與新的 MAC 位址相符：

  • 請檢查 VM 的序列埠輸出內容，確認是否有衝突。請尋找 "Device eth0 has different MAC address than expected, ignoring"、DHCP 逾時錯誤等錯誤，或顯示介面意外重新命名的記錄 (例如 renamed network interface eth0 to eth1)。
  • 連線至互動式序列主控台，並登入執行個體。
  • 執行下列指令，找出新的 MAC 位址和使用中的介面名稱：ip link show

  • 根據發行版本使用的網路管理工具，更新網路設定：

    • 使用 Netplan 的系統 (Ubuntu、Debian 10+ 和部分較新的 Linux)：

      1. 檢查 /etc/netplan/ 中的 Netplan 設定 (例如 /etc/netplan/50-cloud-init.yaml)。
      2. 如果介面的 macaddress: 欄位是硬式編碼 (例如 eth0)，請更新為新的 MAC 位址，或完全移除 macaddress: 行。
      3. 套用更新後的設定：sudo netplan apply
      4. 重新啟動網路服務：sudo systemctl restart systemd-networkd

    • 使用 NetworkManager 的現代系統 (RHEL 9+、Rocky Linux)：

      1. 在 /etc/NetworkManager/system-connections/ 中找出有效的連線設定檔 (尋找 .nmconnection 檔案)。
      2. 開啟主要介面對應的檔案，並在 [ethernet] 設定區塊下找到 mac-address= 行。
      3. 請更新值，使其與新的 MAC 位址相符，或刪除該行，允許動態硬體比對。
      4. 重新啟動 NetworkManager：sudo systemctl restart NetworkManager

    • 使用 ifcfg-scripts 的舊版系統 (RHEL 7/8、CentOS)：

      1. 開啟位於 /etc/sysconfig/network-scripts/ifcfg-eth0 的介面指令碼：sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
      2. 找出 HWADDR= 行，然後更新為新的 MAC 位址，或完全刪除該行，允許動態繫結。儲存並結束。
      3. 重新啟動網路服務：sudo systemctl restart network.service 或 sudo service network restart

  修正網路設定並重新啟動網路堆疊後，請確認 ip addr show 列出指派給介面的有效內部 IP 位址。SSH 存取權現在應可正常運作。

• gcloud CLI 是透過無權連線至 VM 的帳戶進行驗證。如果 gcloud CLI 中的有效帳戶不是您預期的帳戶，或帳戶沒有必要的 IAM 角色，gcloud CLI 就無法將安全殼層金鑰新增至 VM，連線也會失敗。

  請按照下列步驟解決這個問題：

  1. 查看 gcloud CLI 中啟用的帳戶：

     gcloud auth list
     

  2. 如果目前使用的帳戶不是您要用的帳戶，請登入正確的帳戶：

     gcloud auth login ACCOUNT
     

     將 ACCOUNT 替換為有權連線至 VM 的使用者帳戶電子郵件地址。

  3. 確認帳戶具備必要角色。如果 VM 使用以中繼資料為基礎的安全殼層金鑰，您必須具備 Compute 執行個體管理員 (v1) 角色 (roles/compute.instanceAdmin.v1)。如果 VM 是以服務帳戶身分運作，您也必須具備服務帳戶使用者角色 (roles/iam.serviceAccountUser)。如果 VM 使用 OS 登入，請參閱「指派 OS 登入 IAM 角色」。

  4. 重試連線。

• gcloud CLI 使用的安全殼層金鑰組遺失、損毀，或與 VM 上的公開金鑰不符。gcloud CLI 會將安全殼層金鑰組儲存在工作站的 ~/.ssh/google_compute_engine 和 ~/.ssh/google_compute_engine.pub 檔案中。如果遺失私密金鑰，或金鑰組與中繼資料或 OS 登入設定檔中儲存的公開金鑰不符，VM 就會拒絕連線。

  如要確認問題是否僅限於工作站，請使用瀏覽器中的 SSH 連線至 VM。如果瀏覽器中的 SSH 連線成功，問題可能出在工作站上的金鑰檔案或 gcloud CLI 設定。

  如要解決這個問題，請按照下列步驟產生新的金鑰組：

  1. 重新命名現有的金鑰檔案，讓 gcloud CLI 不會使用這些檔案：

     mv ~/.ssh/google_compute_engine ~/.ssh/google_compute_engine.old
     mv ~/.ssh/google_compute_engine.pub ~/.ssh/google_compute_engine.pub.old
     

     在 Windows 上，也請重新命名同一目錄中的 google_compute_engine.ppk 檔案。

  2. 使用 gcloud CLI 連線至 VM：

     gcloud compute ssh VM_NAME
     

     將 VM_NAME 替換為 VM 名稱。

     gcloud CLI 會建立新的金鑰組，並將公開金鑰新增至 VM 的中繼資料或 OS 登入設定檔。

• VM 的磁碟空間或記憶體不足，或訪客環境未執行。上述任何情況都可能導致 VM 無法新增安全殼層金鑰或接受新連線。

  請按照下列步驟解決這個問題：

  • 檢查開機磁碟是否已滿。詳情請參閱「解決磁碟已滿和磁碟調整大小的問題」。
  • 在序列埠輸出內容中搜尋記憶體不足錯誤，檢查 VM 是否記憶體不足。在 Cloud Shell 或已安裝 gcloud CLI 的終端機中，執行下列指令：

  gcloud compute instances get-serial-port-output VM_NAME \
      | grep -i -e "out of memory" -e "oom"
  

  • 確認已安裝並執行訪客環境。詳情請參閱「驗證訪客環境」。

如果錯誤持續發生，請查看 VM 的 SSH 驗證記錄。這些記錄位於 Debian 和 Ubuntu 的 /var/log/auth.log 檔案中，以及 RHEL、CentOS 和 Rocky Linux 的 /var/log/secure 檔案中。如果無法使用 SSH 連線至 VM，您可以不停止 VM，直接查看記錄，方法如下：

• 使用互動式序列主控台登入 VM。
• 檢查從快照建立的開機磁碟副本。

如果無法使用上述任一選項，請停止 VM，將其開機磁碟附加至其他 VM，然後查看該 VM 的記錄。詳情請參閱「非預期錯誤」一文，瞭解診斷不明 SSH 守護程序問題的步驟。

未預期的錯誤

嘗試連線至 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 的問題，您必須以超級使用者身分連線至 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 Daemon 問題。如要診斷不明的 SSH daemon 問題，請查看序列控制台記錄是否有錯誤。

  視序列控制台記錄的輸出內容而定，請嘗試救援 VM，並執行下列操作來修正 SSH Daemon 相關問題：

  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 檔案中刪除主機金鑰，然後重新連線。

中繼資料值過大

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

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

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

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

沒有可用的支援驗證方式

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

No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

這項錯誤最常發生的原因，是 SSH 用戶端過舊。舊版 SSH 用戶端可能不支援新版 VM 所需的 ECDSA 金鑰類型和 SHA-2 雜湊演算法。

舉例來說，如果您嘗試使用 0.75 之前的 PuTTY 版本連線至 Red Hat Enterprise Linux (RHEL) VM，就會發生這項錯誤。

如要解決這個錯誤，請將 SSH 用戶端更新至最新的穩定版本。更新 SSH 用戶端後，請重新嘗試建立 SSH 連線。

因用戶端自訂 SSH 設定導致連線失敗

連線至 Compute Engine 執行個體時，自訂設定可能會意外覆寫 gcloud compute ssh 或標準 SSH 用戶端預期的預設行為。在 Linux 和 macOS 上，這個檔案通常位於 ~/.ssh/config。

這個問題的現象如下：

• 即使執行個體正在運作，且 IAM 權限正確，您仍無法使用 SSH 連線至 VM，並出現 Permission denied (publickey) 等錯誤。
• 其他使用者可以連線至 VM。
• 您可以從其他沒有相同自訂 SSH 設定的用戶端機器連線。

如要診斷問題，請按照下列步驟操作：

1. 如要檢查本機 SSH 設定檔，請查看 ~/.ssh/config 檔案的內容。尋找與 VM 主機名稱或 IP 位址相符的 Host 區段，或可能適用的全域設定 (不含 Host 行)。請檢查下列事項：

   • PubkeyAcceptedKeyTypes：如果出現這個指令，可能會限制允許的公開金鑰類型，並排除 Compute Engine 使用的金鑰。
   • IdentityFile：這項指令可能會強制使用不正確或不存在的私密金鑰。
   • ProxyCommand：Proxy 可能干擾連線。
   • 其他非標準選項，例如 KexAlgorithms、Ciphers 或 HostKeyAlgorithms。

2. 如要測試連線，並取得詳細輸出內容和偵錯資訊，請使用 gcloud compute ssh 指令，並搭配 --verbosity=debug 和 --ssh-flag="-vv" 選項：

   gcloud compute ssh INSTANCE_NAME --zone=ZONE --project=PROJECT_ID --verbosity=debug --ssh-flag="-vv"
   

   更改下列內容：

   • INSTANCE_NAME：要連線的執行個體名稱。
   • ZONE：執行個體所在的可用區。
   • PROJECT_ID：執行個體所在專案的 ID。

   查看輸出內容，找出指出金鑰交換問題、驗證失敗或用戶端提供非預期金鑰類型的訊息。

如要解決自訂設定造成的連線失敗問題，請按照下列步驟操作：

1. 如要確認 ~/.ssh/config 是否為問題原因，請使用 -F none 旗標忽略本機設定檔。這項測試是找出問題最可靠的方法。

   • gcloud CLI：

     gcloud compute ssh INSTANCE_NAME --zone=ZONE --project=PROJECT_ID --ssh-flag="-F none"
     

   • 標準ssh：

     ssh -F none USERNAME@EXTERNAL_IP
     

   更改下列內容：

   • USERNAME：您的 SSH 使用者名稱。
   • EXTERNAL_IP：VM 執行個體的外部 IP 位址。

   如果可以成功連線，表示問題出在 ~/.ssh/config 檔案。

如果先前的測試確認問題出在設定檔，請按照下列步驟修正問題：

1. 進行任何變更前，請先備份設定檔。

   cp ~/.ssh/config ~/.ssh/config.bak
   

2. 找出衝突行。編輯 ~/.ssh/config，並使用 # 符號註解排除任何可能導致問題的自訂設定。每次變更後，請測試連線，找出特定線路。

3. 如要修改或移除設定，請將該行註解排除，還原為用戶端預設支援的金鑰類型。舉例來說，如果 PubkeyAcceptedKeyTypes 導致失敗，請將其註解掉。

用戶端設定最佳做法：

• 避免使用限制性全域設定：僅對需要變更的主機套用特定設定，而非使用廣泛的 Host * 區段。
• 記錄變更：在設定檔中使用註解，說明新增特定自訂設定的原因。
• 使用 -F none 進行測試：疑難排解時，您可以使用 -F none 排除所有用戶端設定衝突。

Windows 錯誤

預先發布版 — Windows 專用 SSH

這項功能適用《服務專屬條款》中「一般服務條款」一節的《正式發布前產品條款》。正式發布前功能是依「原樣」提供，支援服務可能受限。 詳情請參閱推出階段說明。

權限遭拒，請再試一次

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

[e-mail]_ID's password:
Permission denied, please try again.

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

• 您的 gcloud CLI 版本過舊

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

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

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

Permission denied (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 伺服器設定，確保 sshd 設定正確。

連線逾時

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

• VM 尚未完成啟動程序。VM 應該會在幾分鐘內啟動完畢。

  如要解決這個問題，請等到 VM 啟動完畢，再嘗試重新連線。

• 未安裝 SSH 套件。Windows VM 則需要先安裝 google-compute-engine-ssh 套件，才能使用 SSH 連線。

  如要解決這個問題，請安裝 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 名稱。

   注意： 如果您使用 IAP 透過內部 IP 位址存取執行個體，IP 位址可能會有所不同。此外，如果 IP 位址是內部位址，則只能從虛擬私有雲網路內部存取執行個體。

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 交握成功完成，表示軟體防火牆規則未封鎖連線、OS 正確轉送封包，且伺服器正在監聽目的地通訊埠。如果 TCP 握手成功完成，但 VM 不接受 SSH 連線，問題可能是 sshd 守護程序設定錯誤或未正常運作。請參閱作業系統的使用手冊，確認 sshd_config 設定正確。

如要執行 Connectivity Tests，分析兩個 VM 之間的虛擬私有雲網路路徑設定，並檢查程式化設定是否應允許流量，請參閱「檢查 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 名稱

使用序列控制台偵錯

建議您查看序列主控台的記錄，找出連線錯誤。您可以使用瀏覽器，從本機工作站以超級使用者身分存取序列主控台。如果無法透過 SSH 登入，或執行個體未連線至網路，這個方法就相當實用。在這兩種情況下，您仍可存取序列控制台。

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

1. 啟用 VM 序列控制台的互動式存取權。

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 的診斷方法

預先發布版 — Windows 專用 SSH

這項功能適用《服務專屬條款》中「一般服務條款」一節的《正式發布前產品條款》。正式發布前功能是依「原樣」提供，支援服務可能受限。 詳情請參閱推出階段說明。

重設 SSH 中繼資料

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

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

   請稍候片刻，等待變更生效。

2. 重新啟用 Windows 的 SSH

3. 重新連線至 VM。

使用 RDP 連線至 VM

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

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

後續步驟

• 瞭解如何使用 SSH 連線至 Compute Engine 的 Linux VM。