騰訊雲帳號購買優惠 騰訊雲伺服器無法遠端連接 SSH 失敗排查步驟

第一章：問題先定義清楚——你到底卡在什麼環節？

SSH 失敗不是一個原因，而是一串可能。你在本地電腦上看到的錯誤訊息，往往已經把線索藏在裡面：是連不上（超時）、是拒絕連線（Connection refused）、還是連上後驗證失敗（Permission denied / Authentication failed）。在騰訊雲上，這些錯誤對應的排查層級不同：網路安全組與路由通常影響「連不上」，系統防火牆與 SSH 服務通常影響「拒絕」，而金鑰、帳號與權限則影響「驗證失敗」。

因此第一步不是急著改配置，而是把現象記錄下來：連接目標是公網 IP 還是內網 IP？使用的端口是多少（默認 22 但你可能改過）。本地執行 SSH 時的完整錯誤文字（建議直接複製）。同時記下雲端實例的 OS 類型（例如 Ubuntu / CentOS / Debian / 自建系統），因為防火牆與服務名的差異會影響指令。

你可以先做的兩個快速檢查

1）在本地電腦上用「詳細模式」連一次 SSH，讓輸出告訴你卡在哪裡。

若你用 Linux/macOS：

ssh -vvv user@你的公網IP -p 22

若你用 Windows，PowerShell 也可執行：

ssh -vvv user@你的公網IP -p 22

你重點看兩類訊息：一是「timeout」或「No route to host」；二是「Connection refused」；三是「Permission denied」。不同類型就能縮小範圍。

2）確認你連的 IP 是否真的對應該實例。騰訊雲有時候你會用到彈性 IP、或在多個實例之間切換。把「實例詳情頁」裡的公網 IP（或彈性 IP）對照一下，避免把 SSH 打到錯的目標上。

第二章：雲端層排查——先把網路與安全組檢查乾淨

在騰訊雲上，大多數「連不上」類錯誤，最後都落在安全組、端口、路由、或 IP 類型不匹配。你不需要一開始就進系統改設定，先把雲端網路邏輯跑通，能省掉大量時間。

2.1 確認實例狀態：不是每次都能 SSH 但實例已關機

進騰訊雲控制台，查看雲主機實例狀態是否是「運行中」。如果是「停止/重啟中」，SSH 當然連不上。若狀態正常，再進下一步。

2.2 檢查安全組入站規則：SSH 端口有沒有放行？

SSH 預設端口 22，但很多團隊會改成別的端口。你要核對兩件事：

（1）實例系統上 sshd 監聽的端口是什麼；

（2）安全組是否允許對應端口的入站流量。

在控制台找到「安全組」，定位到這台 CVM 所使用的安全組。建議臨時測試時把來源 IP 設為你自己的公網 IP（更安全）；若你是自己測試內網跳板或辦公網，來源網段也要對應。

一個典型的正確規則長相：

• 協議：TCP
• 端口範圍：22（或你實際使用的端口）
• 來源：你的 IP（/32）或你的網段

如果你已經加了規則仍不通，別急著認為「安全組沒問題」。要注意兩個常見坑：

騰訊雲帳號購買優惠 1）你加的是另一個安全組，而實例實際綁定的是不同安全組；

2）規則看似存在，但來源網段不包含你目前的連線來源（尤其你在家裡/出差/換網路時）。

2.3 連的是公網 IP 還是內網 IP：請不要混用

如果你使用的是內網 IP（例如 10.x/172.16.x 這類），在沒有 VPN/專線/跳板機的情況下，你的本地電腦通常是無法直連的。此時錯誤通常是 timeout 或 No route to host。

解法有三種：連公網 IP；使用 VPN/堡壘機；或在同一 VPC/內網環境內進行。

2.4 彈性 IP（EIP）與目的地址一致性

若你綁定了彈性 IP，請確保你 SSH 的目標 IP 正是彈性 IP。很多人用過幾次彈性 IP 後又換回普通公網 IP，結果對不上。

騰訊雲帳號購買優惠 2.5 端口是否在中途被限制：NAT、策略、或目的地址錯誤

騰訊雲側一般不會憑空封掉 SSH，但如果你使用了特定網路拓撲（例如自建網關、堡壘機轉發），就要確認路由與轉發規則。另一些情況則是「目標地址寫錯」，例如把 IP 少打一個數字或把不同實例的 IP 混用。

建議：在控制台確認「實例—網卡—公網地址」與你本地配置完全一致。

第三章：傳輸層判斷——timeout 還是 refused？

騰訊雲帳號購買優惠 你在本地看到的錯誤類型，是最直接的判斷工具。以下提供一個簡單對照表，讓你把排查路線快速選出來。

3.1 Timeout / Operation timed out

多半是「網路路徑或安全組」問題：目的端口沒有對外開放，或目標 IP 沒有可達路徑。

你可以嘗試：

nc -vz 你的公網IP 22

或：

telnet 你的公網IP 22

若超時，優先回到安全組、IP 類型、公網可達性。

3.2 Connection refused

通常表示「網路通了，但目標主機沒有在該端口上等待連線」。例如 sshd 沒有啟動、監聽端口不是 22、或防火牆拒絕了該端口。

這時你就要進入系統層排查。

3.3 Permission denied / Authentication failed

通常表示「連線建立了，但你提供的認證方式不被接受」。常見原因包括：

• 使用錯誤的帳號（user 不存在或被鎖）；
• 私鑰沒對應公鑰；
• sshd 配置禁止密碼或禁止該登入方式；
• 金鑰檔權限不符合（chmod/chown 錯誤）。

這時要看 sshd 的配置與系統權限。

第四章：系統層排查——ssh、端口監聽、防火牆逐項排除

當你判斷網路層應該通了（例如你得到 Connection refused 或已能測到端口可達），接下來就要進入伺服器內部檢查。若你目前連不到 SSH，騰訊雲通常提供「雲端控制台串連」或「重置密碼/重新掛載」等方式來獲得臨時訪問權。無論你採用哪種方式，都遵循同一套排查順序。

4.1 檢查 sshd 服務是否正在運行

登入到伺服器後先做：

對使用 systemd 的常見系統（Ubuntu/CentOS 7+）：

騰訊雲帳號購買優惠 sudo systemctl status ssh || sudo systemctl status sshd

若服務沒在跑，嘗試：

sudo systemctl start sshd

或：

sudo systemctl start ssh

接著檢查是否允許開機自啟：

sudo systemctl enable sshd

4.2 檢查 sshd 監聽的端口與綁定地址

接著確認 sshd 到底監聽在哪個端口、是否綁定在正確的地址上。

使用 ss（推薦）：

sudo ss -lntp | grep ssh

或不 grep：

sudo ss -lntp

你要看到類似：

• 0.0.0.0:22 或 *:22（代表對所有網卡監聽）
• 或 127.0.0.1:22（只允許本機，這會導致外部連不上）

若你看到 ssh 只監聽在 127.0.0.1，那通常是 sshd_config 裡的 ListenAddress 設錯，或預設被改過。

4.3 檢查 sshd 配置檔：/etc/ssh/sshd_config

常見配置位置：

/etc/ssh/sshd_config

檢查以下幾項（用 grep 篩選）：

sudo grep -E '^(Port|ListenAddress|PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AuthorizedKeysFile|AllowUsers|AllowGroups)' /etc/ssh/sshd_config

騰訊雲帳號購買優惠 重點含義：

• Port：如果不是 22，你本地就要改成相對端口。
• ListenAddress：如果改成內網或特定網卡，外部可能連不上。
• PermitRootLogin：若禁止 root 登入，而你用 root 連就會失敗。
• PasswordAuthentication：如果設為 no，你就不能用密碼登入。
• PubkeyAuthentication：如果設為 no，你的金鑰也不會生效。

4.4 防火牆是否阻擋了 22/你自訂的端口

即使 sshd 在跑、也監聽端口，系統防火牆也可能把流量擋掉。常見有 firewalld / ufw / iptables。

4.4.1 firewalld（CentOS 7 常見）

sudo systemctl status firewalld

查看規則：

sudo firewall-cmd --list-all

放行端口（示例 22）：

sudo firewall-cmd --permanent --add-port=22/tcp

重載：

sudo firewall-cmd --reload

4.4.2 UFW（Ubuntu 常見）

sudo ufw status

放行：

sudo ufw allow 22/tcp

或指定端口：

sudo ufw allow 2222/tcp

4.4.3 iptables（老系統或自訂）

sudo iptables -S

如果你看到對入站端口的丟棄/拒絕規則，需要針對 ssh 端口放行並持久化。

⚠️ 這裡提醒一點：排查階段你可能會在遠端操作，修改防火牆時最好能確認不會把自己鎖死。建議在有控制台替代登錄手段的情況下操作，或先在規則上追加再確認。

4.5 SELinux（CentOS/Fedora 常見）可能影響 ssh

若你在 SELinux Enforcing 模式下，有些非標準配置可能導致服務被策略限制。可檢查：

sestatus

若是 Enforcing，查看相關 log 可能需要額外處理。大多數情況下，常規 SSH 不會被策略完全禁止，但若你做過非標準變更，這點就要納入。

第五章：登入失敗的排查——帳號、密碼、金鑰與權限

當你已經排除「連不上」與「端口拒絕」，剩下的多半是「認證失敗」。這一章會把最常見的原因講清楚，並給出可直接檢查的命令。

5.1 確認目標帳號存在且未被鎖定

查看帳號是否存在：

id user

若不存在，直接就是錯帳號問題。

檢查是否被鎖定（不同系統命令略有差異），可先看：

sudo passwd -S user

以及：

sudo chage -l user

5.2 sshd 是否允許密碼登入

若你用的是密碼登入方式，本地通常是：

ssh user@IP

若 sshd_config 裡：

PasswordAuthentication no

你就會遇到 Permission denied（密碼驗證被禁止）。解法是改為允許密碼或改用金鑰登入（通常更推薦金鑰）。

5.3 金鑰登入：公鑰/私鑰是否對得上

最常見的金鑰問題是：你把「另一把私鑰」拿去對這台機器，或公鑰沒寫進正確的帳戶。

先在伺服器上檢查目標用戶的 .ssh 目錄與 authorized_keys：

騰訊雲帳號購買優惠 sudo ls -la /home/user/.ssh

以及：

sudo cat /home/user/.ssh/authorized_keys

再檢查你本地金鑰的指紋是否一致（在本地電腦執行）：

ssh-keygen -lf ~/.ssh/id_rsa.pub

把指紋對上 authorized_keys 裡對應的那把公鑰。

5.4 權限錯誤會讓金鑰「看起來都在但就是不吃」

ssh 對目錄與檔案權限非常敏感。常見正確做法：

• ~/.ssh 目錄權限通常是 700
• authorized_keys 權限通常是 600
• 擁有者與群組要屬於目標用戶

騰訊雲帳號購買優惠 在伺服器端修正示例（依你的系統目錄而定）：

sudo chmod 700 /home/user/.ssh

騰訊雲帳號購買優惠 sudo chmod 600 /home/user/.ssh/authorized_keys

sudo chown -R user:user /home/user/.ssh

修正後重試 SSH。

5.5 PermitRootLogin 與密碼/金鑰策略

如果你使用 root 連，且 sshd 配置不允許 root：

騰訊雲帳號購買優惠 PermitRootLogin no

那你一定會失敗。此時正確做法通常是使用普通用戶登入，再用 sudo 提權（前提 sudo 已配置）。

5.6 你使用了不支援的演算法：舊密碼套件或金鑰類型

較舊系統或特殊安全策略可能不支持新版 SSH 客戶端的演算法組合。這類錯誤通常在 -vvv 輸出裡顯示協商失敗。解法是調整金鑰類型（例如更換成 RSA/ed25519）、或針對演算法進行兼容設定。但這屬於較進階情況，通常要先確認問題確實是協商層。

第六章：日誌才是核心——把錯誤定位到一行字

不管你是連不上、端口拒絕，還是驗證失敗，最後都應該回到日誌。日誌能直接告訴你 sshd 是否有啟動、配置是否載入失敗、以及你嘗試登入時被拒絕的原因。

6.1 查看 sshd 服務日誌

systemd 方式：

sudo journalctl -u ssh -n 200 --no-pager

或：

sudo journalctl -u sshd -n 200 --no-pager

若你想在時間上更精準，配合「重試 SSH」後立即看尾部輸出。

6.2 查看 auth 日誌（許多系統常見）

常見檔案路徑：

/var/log/auth.log（Debian/Ubuntu 常見）

/var/log/secure（CentOS 常見）

你可以執行：

sudo tail -n 200 /var/log/auth.log

或：

sudo tail -n 200 /var/log/secure

關鍵字通常包括：Failed password、Invalid user、Authentication refused、error、sshd_config 語法錯誤等。

6.3 配置修改後要不要重啟？用測試避免把自己鎖死

每次你改了 sshd_config，不要直接重啟後才發現語法錯誤。先測試配置語法：

sudo sshd -t

若沒有輸出，通常表示語法正確。然後重載：

騰訊雲帳號購買優惠 sudo systemctl reload sshd

或：

sudo systemctl restart sshd

接著再回到本地重試。

第七章：常見案例整理——對號入座快速修復

下面把最常見的幾類「看起來很怪但其實很規律」的問題整理成案例。你可以把它當作一張路線圖。

騰訊雲帳號購買優惠 案例 A：本地顯示 timeout，安全組已放行但仍不通

先不要懷疑 SSH。常見原因有：

• 你放行了 22，但 sshd 實際監聽不是 22（改過端口）；
• 你連的其實是內網 IP；
• 你來源 IP 不在規則範圍（例如你在外網時變成另一個公網 IP）；
• 實例網路介面/綁定的安全組不是你以為的那個。

修復策略：先用本地 nc -vz 確認端口是否可達，再核對安全組與 sshd_port 一致。

案例 B：Connection refused

這通常是系統層問題：

• sshd 沒有啟動；
• ssh 服務被禁用或崩潰；
• sshd 配置改錯導致服務起不來（此時 journal 應該有錯誤）；
• 防火牆拒絕了端口。

修復策略：先看 systemctl status，再看 ss -lntp，最後看防火牆規則。

案例 C：Permission denied (publickey)

金鑰不對或權限不對最常見：

• authorized_keys 放錯帳戶；
• 私鑰對不上公鑰；
• ~/.ssh 或 authorized_keys 權限/擁有者不正確；
• sshd 禁止了 PubkeyAuthentication。

修復策略：比對指紋、檢查目錄權限與 sshd 設定。

案例 D：使用 root 登入失敗，但改用普通用戶又能進

多半是 sshd 設定禁止 root：

PermitRootLogin no

修復策略：使用普通用戶，確保 sudo 可用；或在確認安全風險後調整 sshd 設定（不建議直接開 root 登入給外網）。

案例 E：你以為改了 sshd 端口，但安全組與本地沒有同步

改 sshd_config 的 Port 後，必要同步兩件事：

• 雲端安全組放行新端口；
• 本地 SSH 連線使用新端口（-p 新端口）。

另外，如果你改了 Port 但 sshd 沒重啟/重載成功，那會造成你連的是「沒人聽的端口」。所以每次改完都用 ss -lntp 或日誌確認。

第八章：一套建議的標準流程——照做就能收斂

把前面內容濃縮成一個你在任何雲伺服器上都能用的「收斂流程」。你可以照順序走，避免來回跳。

步驟 1：本地先看錯誤類型

timeout / refused / permission denied 分流。記錄完整輸出。

步驟 2：確認你連的是正確的 IP 與端口

公網/彈性 IP 是否正確，端口是否一致（22 或自訂）。

步驟 3：雲端安全組放行對的 TCP 端口與正確來源

來源網段是否包含你的當前公網 IP。確認實例綁定的安全組是同一個。

步驟 4：系統層確認 sshd 服務與監聽狀態

騰訊雲帳號購買優惠 systemctl status、ss -lntp。必要時檢查 sshd 日誌與配置語法（sshd -t）。

步驟 5：檢查系統防火牆

firewalld/ufw/iptables 是否阻擋 ssh 端口。

騰訊雲帳號購買優惠 步驟 6：認證失敗再去查帳號與金鑰權限

authorized_keys、權限 700/600、擁有者正確，並核對 sshd_config 是否允許密碼或金鑰。

第九章：避免再次踩坑的日常建議

很多 SSH 問題不是運氣差，而是變更流程不嚴謹。你可以用幾個簡單的習慣降低再次發生的機率。

9.1 變更 sshd_config 前先做緊急保護

每次改 /etc/ssh/sshd_config 前，先用 sudo sshd -t 測試語法，並確保你有替代登入方式（例如騰訊雲控制台串連）。

9.2 不要只改端口：同步雲端安全策略

端口一旦變更，雲端安全組、內建防火牆、以及本地連線參數要同步更新。這三者任何一個不一致都會失敗。

9.3 金鑰部署用一致的用戶與權限規範

在部署流程中固定：目錄 700、authorized_keys 600、擁有者正確。這比你每次靠經驗猜要可靠得多。

9.4 重試 SSH 時要「對應時間」看日誌

騰訊雲帳號購買優惠 不要改完配置就只看控制台有沒有成功。你應該在重試前後看 sshd 的尾部日誌，讓證據對齊。

結語：SSH 失敗其實是線索題

騰訊雲伺服器 SSH 失敗排查，最怕的是盲改。正確做法是：先把錯誤類型分流，再逐層檢查雲端安全組、傳輸可達性、系統的 sshd 監聽、防火牆，最後才到認證細節。你只要把每一步的驗證結果記下來，問題通常就會在很短時間內被定位。當你能在日志裡看到「為什麼被拒絕」那一行字，就不再是焦慮，而是解題。