Ubuntu VPS 的 SSH 連線錯誤
Ubuntu VPS 的 SSH 存取失敗時，依錯誤訊息選擇檢查方向。本指南區分網路、服務、驗證與主機身分問題，同時保留任何仍可用的存取方式。
VPSuntu・更新日期：・閱讀時間：約 5 分鐘
本篇目錄
記錄一次失敗並保留可用存取
保留任何成功的 SSH 工作階段，並找出供應商復原主控台。下文用戶端指令在電腦的 Linux、macOS 或 WSL 執行；伺服器指令透過現有存取或已驗證的復原主控台執行，不要貼到本機終端機。
將文件專用位址 203.0.113.10 換成伺服器位址；ubuntu、連接埠 22 及金鑰路徑也要換成實際帳號、連接埠與私鑰檔名。先列出用戶端實際套用的設定，再進行一次全新連線：
ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10檢查 hostname、user、port、identityfile 及代理設定。第二個指令會針對這次嘗試停用連線共用。記錄時間與最終錯誤；新的主機金鑰提示需依下方身分驗證章節確認。分享除錯輸出前遮蔽使用者名稱、位址及路徑，絕不分享私鑰。
選擇符合錯誤的分支
小螢幕可左右捲動表格，查看所有欄位。
| 訊息或階段 | 代表的情況 | 下一項檢查 |
|---|---|---|
| 建立連線前出現 Connection timed out | TCP 連線未完成 | 位址、路由、防火牆與供應商狀態 |
| Connection refused | 該位址及連接埠主動拒絕 | 預期連接埠、監聽服務與拒絕規則 |
| Permission denied (publickey) | 已進入 SSH 驗證，但提供的憑證失敗 | 使用者、送出的金鑰與伺服器原則 |
| REMOTE HOST IDENTIFICATION HAS CHANGED | 收到的主機身分與已儲存紀錄不同 | 繼續前先透過可信任管道驗證主機金鑰 |
這些觀察能縮小範圍，但不能證明單一原因。若逾時前除錯輸出已有 Connection established，應調查 SSH 交握及伺服器紀錄，而非認定所有封包都被擋住。
逾時：追查預期網路路徑
比對 ssh -v 顯示的目的地與供應商面板目前位址。使用主機名稱時，過期 DNS 或不同 IPv6 目的地可能導向其他地方。確認此 VPS 需要公開位址、VPN 或跳板主機。
確認執行個體正在運作且有公開路由。在供應商防火牆確認實際 SSH 目的連接埠與目前公開來源位址。家用連線位址可能已變更，而 /32 規則仍未更新。也應透過主控台檢查客體防火牆。
Oracle Cloud 的安全清單、NSG、路由與客體防火牆都會影響連線。保留映像檔隨附規則；安裝 UFW 或清空 iptables 不是診斷步驟。網路配置見Oracle Ubuntu 設定指南。單次 ping 失敗不能證明 SSH 不可用。
連線遭拒：檢查監聽服務
遭拒不代表目的地一定是你預期的 VPS。確認身分與連接埠後，透過現有存取或復原主控台，在伺服器執行以下唯讀檢查：
systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager查看預期位址及連接埠是否有監聽服務，將紀錄與嘗試時間對照。Ubuntu 可能使用 socket 啟動；若 ssh.socket 正在監聽，單憑 ssh.service 未啟動不能認定 SSH 不可用。
sshd -t 不啟動常駐程式，只檢查設定及主機金鑰是否有效。沒有輸出的成功結果不代表網路可達。若回報錯誤，先找出對應檔案或設定，再考慮重新載入，避免盲目重新啟動。
公鑰遭拒：檢查帳號與送出的金鑰
使用供應商初始帳號或自己建立的管理帳號，不要猜測名稱。在用戶端除錯輸出找到實際送出的金鑰指紋。若要減少 agent 送出的無關金鑰，在本機重試：
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10設定中的 IdentityFile 項目仍可能適用，請檢查 ssh -G。若用戶端回報無法讀取金鑰，或私鑰權限過於寬鬆，先修正本機檔案存取，再調整伺服器。
在伺服器檢查目標帳號及其已授權公鑰。本例假設家目錄為 /home/ubuntu，請換成 getent 顯示的路徑：
getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys比對已授權指紋與實際送出的指紋，查看 journal 中的擁有權、權限或帳號原則錯誤。若不使用預設路徑，檢查 AuthorizedKeysFile、載入的設定片段及 Match 規則。供應商管理的金鑰服務也可能改變機制。保留現有授權金鑰，不要停用 StrictModes 或啟用密碼來掩蓋原因。
主機身分變更：重新連線前先驗證
重建或 IP 重新分配可能改變主機金鑰，但非預期變更也可能代表連到錯誤端點或遭攔截。透過已驗證的供應商面板，確認執行個體識別碼與是否有計畫中的重建。
透過可信任的客體主控台，查看與用戶端顯示演算法相符的公開主機金鑰。Ed25519 主機金鑰可使用：
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256將 SHA256 指紋與用戶端警告比對。這是伺服器金鑰，不是登入金鑰，也不是供應商主控台閘道的金鑰。驗證過的替換可能需要更新該伺服器的儲存紀錄；先備份檔案並保留其他項目。不要整份刪除 known_hosts 或略過檢查。若身分變更仍無法解釋，停止連線並調查。
在全新工作階段驗證修正
修正已辨識的位址、使用者、金鑰、特定網路規則或設定錯誤。變更伺服器時保留獨立存取管道，套用前驗證 SSH 設定。新連接埠也可能涉及 socket 啟動設定，不能只重新啟動服務。
停用連線共用後重做原始嘗試，確認新登入到達預期帳號，且所需 sudo 權限可用。舊工作階段保持連線不算這項測試。記錄失敗原因及變更內容；若先前部署中斷，再回到Ubuntu VPS 部署指南。
常見問題
應該重新安裝 Ubuntu 來修好 SSH 嗎？
先診斷。位址、使用者或金鑰錯誤不需要重裝系統，而重裝可能破壞資料。完全沒有存取方式時，使用供應商的復原程序。
主控台能用，是否代表 SSH 也該能用？
不代表。主控台與公開 SSH 走不同路徑；客體監聽服務、帳號驗證及網路規則仍需允許 SSH 連線。