Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

排解 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 連線失敗的網路問題和使用者授權錯誤。

這項工作需要的權限

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

networkmanagement.connectivitytests.create 在 VM 上
networkmanagement.connectivitytests.delete 在 VM 上
networkmanagement.connectivitytests.get 在 VM 上

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

控制台

如果 SSH 連線失敗，您可以選擇「Retry」(重試) 連線，或使用 SSH-in-browser 疑難排解工具「Troubleshoot」(疑難排解) 連線。

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

啟動 SSH 疑難排解工具。

gcloud

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

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

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

如要透過 Identity-Aware Proxy 進行 TCP 轉送，請使用 --tunnel-through-iap 標記排解連線問題。

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

查看結果

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

查看測試結果，瞭解 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-in-Browser 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 登入，您需要Compute 執行個體管理員角色，或服務帳戶使用者角色 (如果 VM 設定為以服務帳戶身分執行)。更新執行個體或專案安全殼層金鑰中繼資料時，需要這些角色。
執行下列指令，確認是否有允許 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 錯誤

權限遭拒 (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 登入 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. 按一下「儲存」，然後重新啟動 VM。
- 停用 OS 登入功能。詳情請參閱「停用 OS 登入」。
金鑰已過期，Compute Engine 刪除了 ~/.ssh/authorized_keys 檔案。如果您手動將 SSH 金鑰新增至 VM，然後使用 Google Cloud 控制台連線至 VM，Compute Engine 會為連線建立新的金鑰組。新的金鑰配對過期後，Compute Engine 會刪除 VM 中的 ~/.ssh/authorized_keys 檔案，包括您手動新增的 SSH 金鑰。

如要解決這個問題，請嘗試下列任一做法：
- 使用 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：連線至執行個體的使用者名稱。如果您在中繼資料中管理 SSH 金鑰，使用者名稱就是您建立 SSH 金鑰時指定的使用者名稱。如果是 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/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 的 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 的問題，您需要以根使用者身分連線至 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 的序列控制台，並以超級使用者身分登入。
無法透過 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)。
- 連線至互動式序列主控台，然後登入執行個體。
- 執行 ip link show，找出新的 MAC 位址和有效介面名稱。
- 根據發行平台使用的網路管理工具，更新網路設定：
  - 使用 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 指令碼的舊版系統 (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 存取權。

路徑	權限
`/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 精靈問題。如要診斷不明的 SSH 精靈問題，請檢查序列控制台記錄是否有錯誤。

根據序列控制台記錄檔的輸出內容，嘗試救援 VM，並執行下列操作來修正 SSH Daemon 相關問題：
1. 將磁碟連接至另一個 Linux VM。
2. 連線至已掛接磁碟的 VM。
3. 將磁碟掛接至 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。如要減輕這項限制的影響，請採取下列任一做法：

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

沒有可用的支援驗證方法

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

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

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

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

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

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

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

這個問題的現象有：

即使執行個體正在執行中，且您的 IAM 權限正確無誤，您仍無法使用 SSH 連線至 VM，並收到類似 Permission denied (publickey) 的錯誤訊息。
其他使用者可以連線至 VM。
您可以從沒有相同自訂 SSH 設定的其他用戶端電腦連線。

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

如要檢查本機 SSH 設定檔，請查看 ~/.ssh/config 檔案的內容。尋找與 VM 主機名稱或 IP 位址相符的 Host 區段，或是可能適用的全域設定 (沒有 Host 行)。請檢查下列事項：
- PubkeyAcceptedKeyTypes：如果存在這項指令，可能會限制允許的公開金鑰類型，進而排除 Compute Engine 使用的金鑰。
- IdentityFile：這項指令可能會強制使用錯誤或不存在的私密金鑰。
- ProxyCommand：Proxy 可能會干擾連線。
- 其他非標準選項，例如 KexAlgorithms、Ciphers 或 HostKeyAlgorithms。
如要測試連線，並取得詳細的偵錯資訊，請使用 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。
查看輸出內容，找出指出金鑰交換問題、驗證失敗，或用戶端提供非預期金鑰類型的訊息。

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

如要檢查 ~/.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 檔案。

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

進行任何變更前，請先備份設定檔。
```
cp ~/.ssh/config ~/.ssh/config.bak
```
找出衝突的行。編輯 ~/.ssh/config，並註解掉 (使用 # 符號) 任何您懷疑會導致問題的自訂設定。每次變更後，請測試連線，找出特定線路。
如要修改或移除設定，請註解掉相關行，還原為用戶端預設支援的索引鍵類型。舉例來說，如果 PubkeyAcceptedKeyTypes 導致失敗，請將其註解掉。

用戶端設定最佳做法：

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

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 套件。您必須先安裝 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 交握：

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

注意： 如果您使用 IAP 透過內部 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 名稱

使用序列控制台偵錯

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

如要登入 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 錯誤

權限遭拒 (publickey)

擁有權

權限

擁有權

權限

連線失敗

擁有權

權限

未預期的錯誤

擁有權

權限

無法連線至後端

主機金鑰不符

中繼資料值過大

沒有可用的支援驗證方法

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

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