騰訊雲帳號安全認證 騰訊雲實例無法遠程連接排查SSH密鑰與密碼錯誤的方法

第一章：先把現象說清楚，排查才不會走偏

很多人遇到「騰訊雲實例無法遠程連接」時，第一反應就是反覆輸入密碼或重新生成密鑰。這樣做不一定錯，但通常浪費時間。因為無法連接可能來自三個層次：網路層、服務層、認證層。其中只有認證層才會直接表現為「SSH密鑰錯誤」或「SSH密碼錯誤」。你若不先判斷是哪一層出問題，就很難縮小範圍。

建議你把連接嘗試時的具體輸出記下來，例如：客戶端顯示「Connection timed out」「No route to host」「Permission denied (publickey)」「Permission denied (password)」「Connection refused」等。不同提示對應的可能原因不同：超時多半是網路或安全組；拒絕多半是服務未啟動或端口未開；Permission denied 才更接近密鑰/密碼不匹配或帳號權限問題。

本文以騰訊雲實例的常見排查路徑為主，核心目標是：當你懷疑 SSH 密鑰或密碼有問題時，能用一套可落地的方法確認並修正，而不是靠運氣反覆嘗試。

騰訊雲帳號安全認證 第二章：快速分流——先判斷是網路問題還是認證問題

在你開始折騰密鑰之前，先做一次「最短路徑」判斷：SSH 端口到底通不通、目標主機是否有回應。這一步能立刻避免大量無用操作。

2.1 檢查安全組與端口放行

騰訊雲上，實例的入站通訊通常受安全組控制。你需要確認兩件事：第一，安全組是否允許入站 TCP 的 22 端口（或你實際使用的 SSH 端口）；第二，允許的來源 IP 是否包含你的跳板機或本機 IP（很多人是把來源設成了某個範圍，結果實際來源不在內）。

若你在多個網段之間跳轉，請記得：你在本地做的測試來源 IP 是本地的真實出口地址，並不是你以為的「內網」或「代理後地址」。

2.2 檢查實例內網卡與防火牆（若你啟用了）

即使安全組放通，如果實例自身啟用了防火牆（如 UFW、firewalld、iptables 規則），也可能阻擋入站。你需要在實例端確認防火牆策略是否允許 SSH 端口。

如果你有辦法透過控制台的「管理員登入/救援模式/重置密碼」等方式進到系統，先確認防火牆狀態；若你完全進不去，就先不要擅自改系統配置，應優先修正安全組或網路規則。

2.3 區分常見錯誤訊息

• Connection timed out：通常是網路不可達或端口被阻斷（安全組/路由/ACL/防火牆）。
• Connection refused：目的主機可達，但該端口上沒有程序在監聽（sshd 未啟動、端口不是 22、或 sshd 配置禁用了）。
• Permission denied (publickey)：密鑰驗證失敗，可能是公鑰沒放對、authorized_keys 格式錯、權限錯，或 sshd 設定限制了某些鑰。
• Permission denied (password)：密碼錯或帳號被鎖、ssh 允許密碼登入被關閉。

當你看到的是 Permission denied，才值得把注意力集中到 SSH 密鑰/密碼。

第三章：SSH 密鑰錯誤排查：從 authorized_keys 到權限細節

SSH 公鑰/私鑰的匹配涉及多個環節：你本地擁有的私鑰是否對應伺服器上放置的公鑰？sshd 是否允許公鑰登入？authorized_keys 是否被 sshd 信任？authorized_keys 的權限是否正確？這些任何一項出錯，都可能導致「密鑰錯誤」的表現。

3.1 先確認使用的帳號是否正確

很多人把密鑰配置好了，但實際登入時指定了錯誤用戶，例如你把公鑰放在了 /home/ubuntu/.ssh/authorized_keys，但你用 ssh root@IP 或 ssh ec2-user@IP 去連。帳號不一致，密鑰自然驗證不會通過。

在你確定客戶端命令時，務必核對：

• ssh 的用戶名（user）是否與公鑰放置的目錄一致
• 你是否在使用正確的私鑰文件（-i 參數）

3.2 檢查 ~/.ssh 與 authorized_keys 是否存在

在伺服器上，針對目標帳號（例如 ubuntu 或 centos），確認：

• 目錄 /home/<user>/.ssh 存在
• 文件 /home/<user>/.ssh/authorized_keys 存在
• 文件內容包含你那把密鑰對應的公鑰（通常是一長串以 ssh-rsa 或 ssh-ed25519 開頭的行）

注意：authorized_keys 的每一行通常對應一把公鑰。若你把整段內容誤放成多行、或含有額外註解與不可見字元，也可能造成解析失敗。

3.3 權限不正確是最常見的「看似密鑰錯」原因之一

sshd 對密鑰文件權限非常敏感。常見規則大致是：

• ~/.ssh 目錄權限通常要嚴格（例如 700）
• authorized_keys 權限通常要嚴格（例如 600）
• 騰訊雲帳號安全認證 所有者與群組必須與目標帳號一致

如果你的 .ssh 目錄或 authorized_keys 權限過寬，sshd 可能會拒絕使用該文件，結果就變成「Permission denied (publickey)」。很多人明明公鑰內容是對的，卻因為權限問題被 sshd 直接忽略。

騰訊雲帳號安全認證 3.4 檢查 sshd 是否允許公鑰登入

即使 authorized_keys 沒問題，sshd 如果禁止了公鑰登入，也會導致拒絕。你需要檢查 sshd 的配置文件（通常在 /etc/ssh/sshd_config）。重點查看：

• PubkeyAuthentication 是否為 yes
• AuthorizedKeysFile 是否符合預期（預設通常就是 .ssh/authorized_keys）
• ChallengeResponseAuthentication、PasswordAuthentication 等是否影響你的嘗試方式
• AllowUsers/DenyUsers（若有）是否把目標帳號排除

修改配置後通常需要重新載入 sshd（例如 systemctl restart sshd），否則改動不會生效。

3.5 用日誌定位：sshd 到底怎麼拒絕你

與其猜測，不如看證據。你可以查看 sshd 日誌（依系統不同位置可能略有差異），例如：

• 使用 journalctl 追蹤 sshd 服務事件
• 查看 /var/log/auth.log 或 /var/log/secure

日誌通常會包含：嘗試的用戶名、拒絕原因（例如密鑰不在 authorized_keys、權限不允許、帳號被禁止等）。當你把日誌內容對照 Permission denied 的提示，你會很快知道問題究竟在「認證資料」還是「ssh 政策」。

第四章：SSH 密碼錯誤排查：不是只有「密碼」才會錯

很多人以為「Permission denied (password)」就是密碼輸錯，但實際上可能是：sshd 禁止密碼登入、帳號鎖定、或用戶的 shell/登錄權限被限制。下面提供一套更系統的排查方法。

4.1 確認 sshd 是否允許密碼登入

在 sshd_config 中確認 PasswordAuthentication 是否為 yes。若你之前為了安全把它設成 no，那你用密碼登入一定失敗，但密鑰方式也可能同時失效（尤其當你同時修改了多項配置）。

若你看到日誌顯示 password authentication disabled，那就不要再懷疑密碼本身了。

4.2 檢查帳號是否被鎖或過期

Linux 系統中帳號可能因為安全策略被鎖定或密碼過期，常見指令包括：

• 檢查帳號狀態（如 passwd -S <user>）
• 查看登錄限制（例如是否在 /etc/shadow 對應欄位顯示已鎖）

如果帳號被鎖，你即便輸對密碼也會被拒絕。這類情況在雲主機中不算少見，尤其是你經過多次救援或重置流程後。

騰訊雲帳號安全認證 4.3 檢查用戶是否允許 SSH 登錄與正確 shell

某些系統會禁用特定用戶的互動式 shell。即便密碼正確，ssh 仍可能因為 nologin 或禁止登錄而失敗。你可以檢查：

• /etc/passwd 中該用戶的 shell 是否正常
• 是否被加入了 DenyUsers/AllowUsers 等限制

4.4 重新載入 sshd 與驗證

修改了 sshd_config 後，一定要確認服務狀態與配置是否生效。可以在伺服器上執行配置檢查（如 sshd 的語法檢查工具），避免因為配置錯誤導致 sshd 無法重新啟動，最後變成「Connection refused」。

第五章：把問題變成可驗證的步驟：一個推薦的排查流程

下面給出一條實務可用的排查順序，你可以照著走，能最快收斂原因。

5.1 第一步：確認網路層可達

• 安全組允許你的來源 IP 與 SSH 端口
• 實例內防火牆允許入站 SSH
• 客戶端錯誤訊息若顯示超時/拒絕，先修網路與服務監聽，再談密鑰/密碼

5.2 第二步：確認 sshd 是否在跑、是否監聽正確端口

• sshd 服務狀態是否正常
• sshd 監聽端口是否是你連的那個（22 或自訂端口）

5.3 第三步：針對密鑰登入失敗，先檢查權限與內容

• authorized_keys 是否存在且包含正確公鑰
• ~/.ssh 與 authorized_keys 權限是否嚴格
• sshd_config 中是否啟用了 PubkeyAuthentication

5.4 第四步：針對密碼登入失敗，先檢查策略是否允許

• PasswordAuthentication 是否允許
• 帳號是否鎖定/密碼是否過期
• shell 是否允許登錄

5.5 第五步：用日誌收尾，確保你不是在猜

• 從 sshd 日誌讀取拒絕原因
• 每次只改一個變量，避免引入多個不確定因素

第六章：常見坑位總結：你可能踩過的「無法遠程連接」原因

下面整理幾個高頻坑位，它們往往讓人以為是「密鑰錯誤」或「密碼錯誤」，但實際原因在別處。

6.1 安全組放行了，但來源 IP 不對

許多用戶在安全組中把來源設成家用網 IP 或某個固定出口，但實際連線時 ISP 動態分配 IP，導致你看到的只是超時。

騰訊雲帳號安全認證 6.2 你改了 sshd_config，結果 sshd 沒起來

配置語法錯誤或參數寫錯，可能導致 sshd 重啟失敗，接著你就從「Permission denied」變成「Connection refused」。這時你應先恢復服務，再談認證。

6.3 公鑰內容有誤或被破壞（格式/換行/複製貼上問題）

authorized_keys 需要精確格式。複製貼上過程中若引入了不可見字元、或把多把公鑰合併成一行，sshd 可能無法解析。

6.4 權限過寬導致 sshd 直接忽略

這是最典型的「內容看起來對，但就是登不進去」。當 .ssh 或 authorized_keys 權限過寬，sshd 會採取安全策略拒絕使用。

6.5 指定了錯誤的私鑰檔案

客戶端連線時，你可能在某次嘗試中沒有用 -i 指定對的私鑰文件，或你的 ssh-agent 里混入了其他密鑰，結果導致握手時使用了錯的 key。

建議在測試時顯式指定私鑰檔，并用客戶端的詳細模式查看使用了哪些 key。

第七章：安全與可恢復性——排查時不要把自己鎖在門外

排查 SSH 問題時，很多操作都可能讓你暫時失去遠程登錄能力。尤其是當你把密碼登入關掉、修改端口、或加入允許/拒絕列表時，若配置錯誤，你可能需要依賴控制台救援才能回來。

因此我建議你遵循兩個原則：

• 每次只改一個方向：例如先只處理 authorized_keys 與權限，確認可登錄後再考慮是否改其他 sshd 參數。
• 留有回退方式：在騰訊雲上確認你有權限使用救援/重置密碼/控制台登入等手段，避免因為操作失誤長時間無法修復。

結語：用日誌與權限把問題「收斂到一個答案」

騰訊雲帳號安全認證 騰訊雲實例無法遠程連接，並不是一個單點故障。當你懷疑 SSH 密鑰或密碼錯誤，最有效的做法是：先用網路層與服務層排除不相干原因，再把認證層拆成「內容對不對」「權限對不對」「sshd 是否允許」。最後用日誌把拒絕原因釘死，你就能快速找到真正的錯誤點並修復。

你不需要一次就成功，也不需要靠猜。只要遵循順序、每次做最小改動、並用日誌驗證，每一次嘗試都會讓你更接近正確答案。當問題被收斂，遠程連接自然會恢復。