本頁面由 Cloud Translation API 翻譯而成。

排解 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-in-browser 疑難排解工具「Troubleshoot」(疑難排解) 連線。

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

啟動 SSH 疑難排解工具。

gcloud

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

gcloud compute ssh VM_NAME \
    --troubleshoot

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

這項工具會提示您提供權限，以執行疑難排解測試。

查看結果

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

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

如果連線失敗，請嘗試手動排解問題，方法如下：
- 使用序列主控台偵錯問題
- 確認 VM 正常啟動

常見的 SSH 錯誤

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

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

未授權錯誤 401

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

Unauthorized
Error 401

如果使用者所屬機構是透過 Google Workspace 管理，且 Workspace 政策中設有有效限制，禁止使用者在 Google Cloud中透過瀏覽器建立 SSH 連線及存取序列埠，就會發生這個錯誤。

如要解決這個問題，請 Google Workspace 管理員按照下列步驟操作：

確認機構已啟用 Google Cloud 。

如果 Google Cloud 已停用，請啟用並重新嘗試連線。
確認已啟用非獨立控制服務。

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

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

以 HTTP 封存格式 (HAR) 檔案擷取網路流量，從您啟動瀏覽器內 SSH 連線時開始。
建立 Cloud Customer Care 案件，並附加 HAR 檔案。

無法連線，重試中...

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

Could not connect, retrying ...

無法連線，重試中

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

VM 啟動完成後，請重試連線。如果連線失敗，請執行下列指令，確認 VM 未以緊急模式啟動：
```
gcloud compute instances get-serial-port-output VM_NAME \
| grep "emergency mode"
```
如果 VM 以緊急模式啟動，請排解 VM 啟動程序問題，找出啟動程序失敗的原因。
在序列控制台中執行下列指令，確認 google-guest-agent.service 服務正在執行。
```
systemctl status google-guest-agent.service
```
如果服務已停用，請執行下列指令來啟用及啟動服務：
```
systemctl enable google-guest-agent.service
systemctl start google-guest-agent.service
```
確認 Linux Google 代理程式指令碼已安裝並正在執行。詳情請參閱「判斷 Google 代理程式狀態」。如果未安裝 Linux Google 代理程式，請重新安裝。
確認您具備連線至 VM 的必要角色。如果 VM 使用 OS 登入，請參閱「指派 OS 登入 IAM 角色」。如果 VM 未使用 OS Login，您需要Compute 執行個體管理員角色或服務帳戶使用者角色 (如果 VM 設定為以服務帳戶形式執行)。更新執行個體或專案 SSH 金鑰中繼資料時，需要這些角色。
執行下列指令，確認是否有允許 SSH 存取的防火牆規則：
```
gcloud compute firewall-rules list | grep "tcp:22"
```
確認有通往網際網路 (或堡壘主機) 的預設路由。詳情請參閱「檢查路徑」。
確認根磁碟區的磁碟空間未用盡。詳情請參閱「解決磁碟已滿和磁碟調整大小的問題」。

執行下列指令，確認 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 錯誤

權限遭拒 (公開金鑰)

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

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

造成這項錯誤的原因可能有很多，以下是造成這項錯誤的一些常見原因：

您使用儲存在中繼資料中的 SSH 金鑰，連線至已啟用 OS 登入的 VM。如果專案已啟用 OS 登入功能，虛擬機會拒絕中繼資料中儲存的 SSH 金鑰。如果不確定是否已啟用 OS 登入，請參閱檢查是否已設定 OS 登入。

如要解決這個問題，請嘗試下列其中一種方法：
- 使用 Google Cloud 控制台或 Google Cloud CLI 連線至 VM。詳情請參閱「連線至 VM」。
- 將安全殼層金鑰新增至 OS 登入功能。詳情請參閱將金鑰新增至使用 OS 登入功能的 VM。
- 停用 OS 登入。詳情請參閱「停用 OS 登入」。
您使用儲存在 OS 登入設定檔中的 SSH 金鑰，連線至未啟用 OS 登入的 VM。停用 OS 登入後，虛擬機會拒絕接受儲存在 OS 登入設定檔中的 SSH 金鑰。如果不確定是否已啟用 OS 登入，請參閱檢查是否已設定 OS 登入。

如要解決這個問題，請嘗試下列其中一種方法：
- 使用 Google Cloud 控制台或 Google Cloud CLI 連線至 VM。詳情請參閱「連線至 VM」。
- 啟用 OS 登入。詳情請參閱「啟用 OS 登入」。
- 將安全殼層金鑰新增至中繼資料。詳情請參閱將 SSH 金鑰新增至使用中繼資料型 SSH 金鑰的 VM。
VM 已啟用 OS 登入，但您沒有足夠的 IAM 權限可使用 OS 登入。如要連線至已啟用 OS 登入功能的 VM，您必須具備 OS 登入所需的權限。如果不確定是否已啟用 OS 登入，請參閱檢查是否已設定 OS 登入。

如要解決這個問題，請授予必要的 OS Login 身分與存取權管理角色。
金鑰已過期，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」。
- 將安全殼層金鑰重新新增至中繼資料。詳情請參閱將 SSH 金鑰新增至使用中繼資料型 SSH 金鑰的 VM。
您使用第三方工具連線，但安全殼層指令設定錯誤。如果您使用 ssh 指令連線，但未指定私密金鑰的路徑，或指定了錯誤的路徑，虛擬機器就會拒絕連線。

如要解決這個問題，請嘗試下列其中一種方法：
- 執行下列指令：
```
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」檔案
  擁有權
  訪客環境會將授權的 SSH 公開金鑰儲存在 $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 的權限或擁有權有誤。

擁有權
訪客環境會將授權的 SSH 公開金鑰儲存在 $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。

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

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

無法連線

從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 或公開網際網路的流量。如果防火牆規則不允許來自 IAP 或 TCP 輸入流量的連線 (IP 範圍為 0.0.0.0/0)，系統會拒絕安全殼層連線。

如要解決這個問題，請按照下列其中一種做法進行：
- 如果您使用 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 的問題，請以根使用者身分連線至 VM 的序列控制台。

如要解決這個問題，請嘗試下列一或多個做法：
- 請參閱您作業系統適用的使用手冊，確保已正確設定 sshd_config。
- 請確認您已為下列項目設定必要的擁有權和權限：
  - $HOME 和 $HOME/.ssh 目錄
  - 「$HOME/.ssh/authorized_keys」檔案
  擁有權
  訪客環境會將授權的 SSH 公開金鑰儲存在 $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 的序列埠控制台，並以超級使用者身分登入。

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

非預期的錯誤

嘗試連線至 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」檔案
  擁有權
  訪客環境會將授權的 SSH 公開金鑰儲存在 $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 精靈問題，請檢查序列控制台記錄是否有錯誤。

請根據序列控制台記錄檔的輸出內容，嘗試救援 VM 並修正 SSH Daemon 相關問題，方法如下：
1. 將磁碟連接至其他 Linux VM。
2. 連線至已掛接磁碟的 VM。
3. 將磁碟掛接至 VM 內的 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。

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

無法連線至後端

從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 登入。

沒有可用的支援驗證方法

連線至 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 連線。

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。如要進一步瞭解如何設定中繼資料，請參閱設定自訂中繼資料。

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 交握：

取得 VM 的外部 natIP：
```
gcloud compute instances describe VM_NAME \
    --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
```
將 VM_NAME 替換為無法連線的 VM 名稱。

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

從工作站測試與 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 之間的虛擬私有雲網路路徑設定，並檢查程式化設定是否應允許流量，請參閱「檢查 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 問題，請按照下列步驟操作：

啟用互動存取權，存取虛擬機的序列埠主控台。
如果是 Linux VM，請修改根密碼，並在 VM 中新增下列開機指令碼：
```
echo root:PASSWORD | chpasswd
```
將 PASSWORD 替換為您選擇的密碼。
使用序列埠主控台連線至 VM。
如果是 Linux VM，偵錯完所有錯誤後，請停用根帳戶登入功能：
```
sudo passwd -l root
```

Linux VM 的診斷方法

檢查但不關閉 VM 執行個體

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

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

建立磁碟快照，備份開機磁碟。
從快照建立一般永久磁碟。
建立臨時執行個體。
將一般永久磁碟連結並掛接到新的暫時執行個體。

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

建立託管複製執行個體的新虛擬私人雲端網路：
```
gcloud compute networks create debug-network
```
將 NETWORK_NAME 替換為新網路的名稱。

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

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

建立開機磁碟的快照。

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

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

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

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

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

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

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

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

請按照操作說明透過防禦主機連線至 VM。

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

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，在中繼資料生效前重設執行個體。

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

使用 --keep-disks 旗標執行 gcloud compute instances delete。
```
gcloud compute instances delete VM_NAME \
   --keep-disks boot
```
將 VM_NAME 替換為無法連線的 VM 名稱。
新增具有相同磁碟的新執行個體並指定開機指令碼。
```
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。

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

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

刪除無法連線的 VM，並保留其開機磁碟：
```
gcloud compute instances delete VM_NAME \
   --keep-disks=boot 
```
將 VM_NAME 替換為無法連線的 VM 名稱。
使用舊 VM 的開機磁碟建立新 VM。指定您剛刪除的 VM 開機磁碟名稱。
使用 SSH 連線至新的 VM：
```
gcloud compute ssh NEW_VM_NAME
```
將 NEW_VM_NAME 替換為新 VM 的名稱。

檢查 VM 開機磁碟是否已滿

如果 VM 的開機磁碟已滿，您可能無法存取 VM。如果 VM 連線問題是由於開機磁碟空間不足所致，可能難以察覺，因此這類情況的疑難排解作業可能較為困難。如要進一步瞭解這個情況，請參閱「排解因開機磁碟空間已滿而無法存取 VM 的問題」。

Windows VM 的診斷方法

重設 SSH 中繼資料

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

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

稍待幾秒鐘，等待變更生效。
重新啟用 Windows 的 SSH
重新連線至 VM。

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

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

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

後續步驟

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

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

SSH 疑難排解工具

執行疑難排解工具

這項工作需要的權限

主控台

gcloud

查看結果

常見的 SSH 錯誤

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

未授權錯誤 401

無法連線，重試中...

Linux 錯誤

權限遭拒 (公開金鑰)

擁有權

權限

擁有權

權限

無法連線

擁有權

權限

非預期的錯誤

擁有權

權限

無法連線至後端

主機金鑰不相符

中繼資料值過大

沒有可用的支援驗證方法

Windows 錯誤

權限遭拒，請再試一次

Permission denied (publickey,keyboard-interactive)

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

連線逾時

診斷 SSH 連線失敗的原因

Linux 和 Windows VM 的診斷方法

測試連線能力

檢查您的防火牆規則

測試網路連線

Linux、Windows 2019/2022 和 macOS

Windows 2012 和 2016

以其他使用者身分連線

使用序列主控台偵錯問題

Linux VM 的診斷方法

檢查但不關閉 VM 執行個體

使用開機指令碼

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

檢查 VM 開機磁碟是否已滿

Windows VM 的診斷方法

重設 SSH 中繼資料

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

後續步驟

排解 SSH 錯誤