Azure帳號註冊服務 Azure創建Linux虛擬機SSH密鑰丟失

前言：為什麼會遇到「Azure 創建 Linux 虛擬機 SSH 密鑰丟失」

Azure帳號註冊服務 我第一次遇到這種狀況，是因為自己當初在建立 Azure Linux 虛擬機時，私鑰只在本機某個資料夾裡。後來換了電腦、重裝系統，又把那個專案文件夾清掉了。當我再次想用 SSH 連回來時，終端機直接報錯：密鑰檔案不存在、或私鑰不匹配。那瞬間你會有一種很直覺的判斷：是不是「密鑰丟了就完全沒救」？

但現實並不是這樣。Azure 建立虛擬機時，真正被保存在實例端的是「公鑰」的內容；而你本機用來登入的「私鑰」只是用來證明身份。丟了私鑰，通常意味著你失去那組身份的能力，但並不等於你無法進入系統。只要你還能透過 Azure 的管理介面取得救援入口，就可以重設或更換登入方式。

本文我會把「密鑰丟失」拆成幾種典型來源，並給出能落地操作的解法。你可以不用記住所有指令，但要知道每一步在修什麼，才能避免越修越亂。

第一章：先判斷問題屬於哪一種「丟失」

Azure帳號註冊服務 在開始救援前，先花兩分鐘把狀況定義清楚。因為不同原因會導向不同做法。很多人不是因為密鑰真的不見了才登不進去，而是「密鑰還在，卻用錯了」或「實例根本沒接到那把公鑰」。

1.1 私鑰檔真的不在了

你在本機找不到 .pem 或 .ppk 檔，或檔案在但已經不是原始那份。這是最常見的情形。此時結論通常是：你不能再用原本那把私鑰登入。

1.2 私鑰存在，但權限不正確

Linux/類 Unix 用 SSH 會要求私鑰檔權限很嚴格。如果你把檔案權限改鬆（例如太寬），SSH 可能會拒絕使用。這類情況的錯誤訊息常見會像「Permissions are too open」。

1.3 你拿到的不是同一組密鑰（公私鑰不匹配）

例如你以為自己下載的是那份私鑰，但其實下載的是另一個資源群組、另一個實例，或同名檔覆蓋了。這時你會看到「Authentication failed」或「Bad permissions」以外的錯誤訊息。

1.4 實例建立時公鑰沒有成功寫入

有些人是用模板、腳本、或手動輸入公鑰。若流程中途發生錯誤，或你以為填了公鑰但其實填的是空值/錯誤內容，最終實例端沒有對應的 authorized_keys。這種情況即使你手上有正確私鑰也仍然進不去。

1.5 你登入的是錯的帳號或用錯了網路路徑

有時候不是密鑰問題，而是你用錯了使用者（例如建立時的預設帳號是 azureuser，但你登入卻用 ubuntu）、或網路規則不放行 22/或 NSG 擋掉。

所以，建議你第一時間先確認：你是否能在 Azure 上存取到 VM 的串連控制台（Serial Console）、是否允許 SSH 入站、以及 VM 使用的使用者帳號是什麼。

第二章：不要先急著重裝 VM，把「可用入口」找出來

密鑰丟失時，最怕的就是你做太激進的動作，例如直接刪機器或重裝系統。其實你應該先做的是：找出 Azure 仍然能讓你進到機器的方法。通常最實用的是：Azure Serial Console（序列控制台）或救援模式。

你不需要立刻會所有 Azure 操作，只要知道順序：先嘗試能否用管理通道進入，再處理帳號登入方式；比起在黑暗中反覆猜密鑰，這更快。

2.1 檢查 SSH 是否真的對你開著

先在 Azure 介面確認 NSG（網路安全群組）或防火牆設定。尤其如果你是在新的資源群組或新 VNet，忘記打開 22/或只允許特定來源 IP 的情況很常見。若連 22 都不通，無論你密鑰對不對都一樣失敗。

你可以用兩種方式判斷：其一，直接在 Azure 顯示「正在允許 SSH」的安全規則是否存在；其二，用你本機嘗試連線後檢查錯誤型態（timeout 通常像是網路層擋住）。

2.2 檢查 VM 的登入使用者名稱

Azure 建立 VM 時會要求你指定管理帳號（例如 admin username）。你需要確認那個帳號是不是你目前用來 SSH 的帳號。很多人以為是固定 ubuntu，但其實可能是別的。

2.3 啟用並使用 Azure Serial Console

如果你的 VM 在建立時或之後啟用了 Serial Console（以及你有相應權限），這會是最直接的救援入口。你可以從 Azure Portal 進入 VM 的串連控制台，得到一個類似本機終端的界面。密鑰丟了也不怕，因為你可以在控制台中重新配置 authorized_keys 或重設密碼。

如果你當初沒有啟用 Serial Console，那就進入下一節的救援模式路線。

第三章：密鑰丟失時，最有效的三條路

我把解法整理成三條路。你不需要全做，選一條最合適的。它們的差別在於「你能不能拿到控制台入口」以及「你希望用密鑰還是改用密碼登入」。

3.1 方案 A：透過串連控制台重設 authorized_keys（推薦）

如果你能進到 VM 的 shell（例如 Serial Console），那你就可以直接把新的公鑰加入到目標帳號的 ~/.ssh/authorized_keys。這是最乾淨也最符合「用 SSH 密鑰登入」的做法。

流程大致如下：

• 在你本機重新產生一把新的 SSH key（或找回正確的那把公私鑰）
• 把新的公鑰內容貼進 authorized_keys
• 設定權限與擁有者
• 確保 SSH 服務正常

在 VM 上你通常會做這些操作（這裡以假設目標帳號是 adminuser 為例）：

Azure帳號註冊服務 sudo mkdir -p /home/adminuser/.ssh
sudo nano /home/adminuser/.ssh/authorized_keys

把新的公鑰一行貼進去後保存。接著設定權限：

sudo chmod 700 /home/adminuser/.ssh
sudo chmod 600 /home/adminuser/.ssh/authorized_keys
sudo chown -R adminuser:adminuser /home/adminuser/.ssh

最後你可以在本機用新的私鑰重新 SSH：

Azure帳號註冊服務 ssh -i /path/to/newkey.pem adminuser@你的VM公網IP

你會發現密鑰丟失在技術上並不可怕，真正可怕的是你沒有入口修改 authorized_keys。

3.2 方案 B：重設該帳號密碼後再登入（備用，但常用）

如果你進不了串連控制台，又或你不想處理 authorized_keys 的細節，另一條路是重設 VM 的帳號密碼（Azure 通常提供「重設密碼」的管理能力）。重設後你可以用密碼登入，再進一步恢復密鑰登入。

這個方案的優點是速度快；缺點是安全性上需要你立刻再把密鑰恢復好，並在登入後將密碼方式降權或移除（至少要確保你不把弱密碼長期保留）。

常見做法是：先用重設密碼登入成功，立刻把新的公鑰加入 authorized_keys，然後把密碼僅保留到你確認密鑰可用為止。

3.3 方案 C：用救援模式進入系統做修復（當你沒有 Serial Console）

若串連控制台不可用，Azure 的救援模式（Rescue）可能是你最後的方式。它允許你在某種管理通道下取得 root 或接近 root 的操作權限，進而修改檔案。

你要做的事本質仍然是同一件：更新 authorized_keys 或重設帳號設定。

只要你進得去系統，修復步驟就一致：確認目標帳號是誰、.ssh 目錄是否存在、authorized_keys 是否正確、權限是否正確。很多人卡住不是因為方法不行，而是忘了權限。

第四章：把公鑰正確寫入 authorized_keys，避免又一次「看似對但就是不行」

密鑰設定成功與否，通常取決於三個細節：內容是否正確、一行一個 key、以及權限是否符合 SSH 的要求。這三個問題是最常見的失敗點。

4.1 每個公鑰一行，不要混入多餘格式

authorized_keys 應該是純文字，通常是一行一把 key。不要在公鑰前後包多餘引號、不要把「-----BEGIN PUBLIC KEY-----」整段原封不動貼進去（除非你確定格式本來就符合 authorized_keys 的期望）。

Azure帳號註冊服務 正確的公鑰通常以 ssh-rsa 或 ssh-ed25519 開頭，後面是一段長字串。

4.2 權限錯誤會直接讓 SSH 忽略你的 key

SSH 對 ~/.ssh 與 authorized_keys 非常嚴格：

• ~/.ssh 通常要是 700
• authorized_keys 通常要是 600
• Azure帳號註冊服務 目錄與檔案的擁有者要是目標帳號

只要你其中一項不符合，SSH 可能不會給你直觀的錯誤訊息，只會表示「密鑰拒絕」。所以你每次修正後都值得再檢查一遍。

4.3 authorized_keys 位置要對

很多人會把 key 貼到 root 的 authorized_keys，結果登入的帳號不是 root，自然就失敗。確保你貼到正確帳號的家目錄。

你可以在系統中先確認家目錄位置（例如 /home/adminuser），再確定檔案路徑。

4.4 檢查 SSH 服務與登入限制

若你確定 key 寫對了，但仍無法登入，可能是 SSH 服務未啟動或配置阻止密鑰登入。例如 /etc/ssh/sshd_config 中的 PasswordAuthentication、PubkeyAuthentication 等設定。

你可以在救援環境中先確認服務狀態，例如：

sudo systemctl status ssh
sudo systemctl restart ssh

再檢查是否有特殊限制，如只允許某些使用者或某些網段。

第五章：從根本建立可重現的流程，讓你不再「找不到密鑰」

Azure帳號註冊服務 修復只是第一步，真正重要的是避免下一次再遇到相同問題。這裡我講幾個我自己覺得最實際的做法，不需要很複雜。

5.1 密鑰檔一定要有版本管理與備份策略

你可以把私鑰加密後存放到可信的地方。至少做兩份備份：一份放在你常用環境，一份放在另一個安全位置（例如加密雲端或離線介質）。

重點是「你換電腦或重裝系統時還能拿到」。密鑰丟失往往不是技術失敗，而是流程失敗。

5.2 不要把建立 VM 與密鑰生成綁死在手動操作

如果你常建 VM，建議把公鑰生成與部署流程腳本化，或用 IaC（例如模板/自動化部署）固定公鑰來源。這樣就算你忘了當時下載哪份檔案，也能從流程再現你要用的那組公鑰。

手動操作最大的風險，是每次都「臨時決策」。臨時決策累積到一定程度，就會變成難以追溯的混亂。

5.3 優先使用新的 key，不要在錯誤狀態下反覆猜

當你已經確定「可能丟失或不匹配」，不要浪費時間去猜那把 key 的文件名。正確做法是：直接生成新 key，重新寫入 authorized_keys。這樣能把問題從「猜檔案」轉回「確定可操作的修復」。

5.4 用集中管理降低人為失誤

如果你是團隊使用，建議把公鑰/部署資料交給集中管理方式。至少確保任何實例都有可追溯的登入方式（例如 Key Vault 或可重現的部署腳本）。

你不需要一次做到最完美，但要做到：你未來 6 個月後仍知道怎麼登入。

第六章：一個常見案例的完整救援路徑（讓你照著做）

假設你現在的狀況是：

• Azure VM 已建立成功
• 你丟了私鑰（.pem 不見了）
• SSH 無法登入
• 你能登入 Azure Portal

你可以照下面順序做。

6.1 在 Azure Portal 找到 VM 的管理入口

進入 VM 概覽頁面，檢查是否能看到 Serial Console。若可以，就直接開啟控制台。

同時確認你使用的使用者名稱是不是你建立時設定的 admin username。

6.2 在本機產生新的 key

在你現在的電腦上產生新的私鑰與公鑰（選一種你熟悉的方式即可）。產生後你會得到：

• 私鑰：用來登入
• 公鑰：用來寫入 authorized_keys

把公鑰內容複製一行（通常以 ssh-ed25519 或 ssh-rsa 開頭）。

6.3 在控制台登入後寫入 authorized_keys

假設你的帳號是 adminuser，你在 VM 端執行：

sudo mkdir -p /home/adminuser/.ssh
sudo nano /home/adminuser/.ssh/authorized_keys

把新公鑰貼進去，保存退出。再執行權限修正：

sudo chmod 700 /home/adminuser/.ssh
sudo chmod 600 /home/adminuser/.ssh/authorized_keys
sudo chown -R adminuser:adminuser /home/adminuser/.ssh

6.4 從本機用新私鑰測試登入

在你的終端機輸入：

ssh -i /path/to/newkey.pem adminuser@VM公網IP

若仍失敗，先回去看錯誤訊息。若是網路 timeout，多半是 NSG 擋住；若是 Authentication failed，多半是 key 沒貼對或權限不對。

6.5 若你沒有控制台，就先重設密碼再補密鑰

若你無法進控制台，就使用 Azure 的重設密碼能力。重設後用密碼登入，然後立即做 authorized_keys 的更新，回到密鑰登入。這能避免你把風險長期留在「密碼登入」。

第七章：排查清單（讓你少走彎路）

當你照做了還是失敗，可以按這份清單快速定位原因。

Azure帳號註冊服務 7.1 SSH 連線層

• 你是否有連到正確的 IP（公網/私網）
• NSG 或防火牆是否允許 22
• 是否因為路由或 VPN/Private Endpoint 導致連線不到

7.2 帳號層

• 使用者名稱是否正確
• 該帳號是否被鎖定或禁止登入

7.3 密鑰層

• authorized_keys 是否在正確路徑
• key 是否為正確格式（authorized_keys 需要的那種純內容）
• 權限是否符合 700/600，擁有者是否正確
• 目標帳號的 home 目錄是否存在

7.4 服務與設定層

• sshd 服務是否運行
• 是否關閉了 PubkeyAuthentication
• 是否配置了僅允許特定 IP 或機制

結語：密鑰丟失不是結局，而是提醒你要改流程

「Azure 創建 Linux 虛擬機 SSH 密鑰丟失」聽起來像是災難，但它更像是一個流程警報。技術上，你只要能進到 VM 的管理入口，就可以重新寫入 authorized_keys，讓登入回到你能控制的狀態。真正需要被修正的，是你如何管理私鑰與部署資訊，讓未來你不必依賴運氣。

如果你現在正卡在無法 SSH，請先停一下：先確認網路是否通、使用者是否正確，再找 Azure 的串連控制台或救援模式。找到入口後，重設或更換公鑰通常是最快的路。當你把這次救回來，下次就該把密鑰備份、部署流程固化，讓「丟了」不再變成「只能看天吃飯」。