AWS認證帳號 AWS EC2 密鑰丟失怎麼重置密碼
第一章：先搞清楚，你丟的是哪一把「鑰」
AWS認證帳號 很多人說「密鑰丟了」，但在 AWS EC2 這件事上，真正卡住的常常不是系統壞了，而是你手上的「私鑰」不見了。EC2 的登入流程本質上靠兩件事：一個是你在 AWS 建立 Key Pair 時生成並下載的私鑰檔（.pem 或 .ppk），另一個是 AWS 端保存的公鑰（public key）。公鑰在 AWS，私鑰在你電腦。你丟了私鑰，就等於你失去用 SSH 私密驗證的能力。
因此第一步不是急著「重置密碼」，而是確認你目前是哪種狀況：
- 你確定是私鑰檔不見：例如找不到 .pem，或換電腦後忘了保存位置。
- 你其實私鑰檔還在，但連不上：可能是檔案權限、登入用戶、目標安全群組/網路、防火牆設定錯誤。
- 你無法 SSH，但系統仍可透過其他管道管理：例如已啟用 SSM（AWS Systems Manager）或你有 Console 內部存取方式。
- 你完全無法連線：包含安全群組、網路 ACL、或 instance 狀態限制，且也未啟用替代管理。
把狀況釐清後，你才有機會選擇成本最低、風險最可控的方法。下面我會把常見情境分成幾種路徑，讓你能直接對照。
第二章：EC2「重置密碼」其實要先理解限制
EC2 的 SSH 登入不是像傳統網站「寄回密碼」那麼簡單。AWS 的 Key Pair 是用來做登入驗證的，並不是單純的系統帳號密碼。你在登入時使用的通常是：
- Linux：使用私鑰做 SSH 驗證。
- Windows：使用系統管理或指定憑證流程（例如透過 EC2 Serial Console / 解鎖 Administrator 之類的機制）。
如果你丟的是 Linux 的私鑰檔，那就算你改了系統裡的密碼，也不一定能讓你完成登入——因為你可能還是打算用 SSH Key 登入。如果你改用「密碼登入」（password authentication），還要同時確認 SSH 設定允許、也要有方法改動該設定。
所以更正確的問題通常是：你是否能取得系統層面的控制，從而重新讓登入可行？這就牽涉到「你能不能觸及 instance 的系統磁碟或執行通道」。AWS 提供了幾條救援通路，依你是否事先做了設定而不同。
第三章：最佳解法通常不是暴力重置，而是利用你已啟用的管理能力
很多人忽略了：如果你在建立 instance 時啟用過 AWS Systems Manager（SSM），那你可能不用碰 Key Pair 也能改設定、重建使用者或重新安裝 SSH 金鑰。這是最乾淨、風險最低的路線之一。
情境 A：你已啟用 SSM（能用 Session Manager 進去）
當 instance 綁定了正確的 IAM 角色（SSM 需要的權限）、並且 instance 能連到 SSM（透過公網或 VPC endpoint/NAT），你就可以用 Session Manager 取得 shell。這時「私鑰不見」不是致命問題。
AWS認證帳號 操作邏輯通常是：
- 在 AWS Console 找到該 EC2 instance，檢查是否顯示可用的 SSM 狀態。
- 開啟 Session Manager，進到系統。
- 在系統內把你的新 SSH 公鑰寫入用戶的 ~/.ssh/authorized_keys。
- 必要時調整檔案權限（例如 ~/.ssh 目錄與 authorized_keys 檔）。
- AWS認證帳號 再用你手上的新私鑰嘗試 SSH。
這樣做的優點是：不必停機、不必改網路安全群組、不必動磁碟。唯一要注意的是，你是否能「得到系統權限」。如果 SSM 沒開，你就走下一段。
情境 B：你沒有 SSM，但仍能用其他路徑存取（例如控制台救援或特定登入機制）
有些環境會用到 console-based 的救援工具（例如透過 EC2 的某些管理介面）或你仍有另一種方式連到機器，例如既有自動化運維通道。若你能在系統內操作，做法仍然類似：更新 authorized_keys 或建立新用戶並配置權限。
但大部分一般使用者遇到的是：完全依賴 SSH Key，因此陷入僵局。這時需要更「工程化」的救援思路。
第四章：重新建立 Key Pair 不能直接「解鎖」你丟掉的私鑰
常見誤解是：既然 Key Pair 丟了，那我在 AWS 再建立一個新的 Key Pair，然後把它綁回 instance，就能立即登入。理論上「可以讓未來登入使用新私鑰」，但實務上有個關鍵限制：
你在建立 Key Pair 時，AWS 只保存公鑰。instance 的 /home/ubuntu/.ssh/authorized_keys（或相應用戶）裡原本寫入的是「舊公鑰」。如果你只是修改 instance 的 Key Pair 欄位（有時可在建立或某些情境更新），並不保證已寫入磁碟的 authorized_keys 會自動同步更新。
因此你必須確認你所選的方法是否真的改到磁碟內的 authorized_keys，而不是只改了 AWS 端顯示。下面給你幾個更符合實務的做法。
第五章：沒有 SSM 時的常用救援路線——更換啟動磁碟或修改 authorized_keys
當你既沒有 SSM，又丟了私鑰，你唯一穩定的方向通常是：讓自己能對 instance 的系統磁碟做修改。AWS 上可行的方法會因系統類型（Linux/Windows）、啟動方式（EBS/Instance Store）、你能否停機、你是否有額外權限而不同。
對多數 Linux（EBS 型）情境，常見思路是把根磁碟掛載到一個「救援環境」，然後把新的公鑰寫進去。
核心概念：掛載原磁碟到另一台救援主機
你可以把原本 EC2 instance 的 EBS 根磁碟（或資料磁碟）掛載到一台臨時 EC2 或救援環境中。接著你就能修改：
- 對應用戶的 ~/.ssh/authorized_keys
- 必要的 SSH 設定（例如 PermitRootLogin、PasswordAuthentication、或其他防護設定）
- 必要時建立新用戶
完成後再把磁碟放回原 instance，重啟，最後用新私鑰登入。
實務步驟（Linux + EBS 常見）
下面用較通用的流程描述，讓你能按步對應操作；具體按鈕與名稱可能因 AWS Console 版本稍有不同。
- 先建立新的 Key Pair：在 AWS 建立一個新的 Key Pair，下載新的私鑰檔保存好（之後登入會用到）。
- 停掉目標 instance（必要時）：因為你要操作 EBS 卷，停機有助於避免磁碟一致性問題。
- 找到 instance 使用的根磁碟（EBS volume）：確認 Volume ID。
- 建立一台救援 EC2 或使用現成映像：救援機只需能掛載該 EBS volume，並且能讓你在救援機上執行編輯檔案的操作。通常會選用 Linux 套件較完整的映像。
- 將原 EBS volume 掛載到救援機：在救援機上把 volume 挂載到某個目錄。
- 找出目標用戶目錄：常見是 /home/ec2-user、/home/ubuntu，或你自建的登入用戶。你可以查看 /etc/passwd 或目錄結構來判斷。
- 把新的公鑰寫入 authorized_keys：
一般做法是把新的公鑰追加到對應用戶的 ~/.ssh/authorized_keys。若目錄不存在就建立。注意檔案權限與擁有者，否則 SSH 會因權限不安全而拒絕使用金鑰。
- 調整權限：常見要求是 ~/.ssh 目錄權限為 700，authorized_keys 檔權限為 600，且擁有者為目標用戶。
- 解除掛載並把 volume 放回原 instance。
- 啟動原 instance。
- 確認 SSH 能登入：使用你新下載的私鑰連線，並確認安全群組允許來源 IP。
這套流程本質上是「重建能讓你登入的授權材料」，而不是憑空重設密碼。對於 Key Pair 遺失的問題，它最可靠。
你可能會遇到的坑
- 不知道用戶名：例如你以為是 ubuntu，但其實實際登入用戶是 ec2-user。這會導致你改了錯的目錄，最後登入仍失敗。
- authorized_keys 實際不在預期位置：某些映像會改用不同用戶，或你曾經修改过 SSH 設定。
- AWS認證帳號 SSH 被強化或關閉 Key 登入：例如某些系統允許 password 禁止 key，或反向。你需要看 /etc/ssh/sshd_config 或相關設定檔。
- 安全群組與網路仍阻擋：就算你把 authorized_keys 修好，如果安全群組不允許 22（或你改過端口），你依然連不上。
遇到失敗時，不要急著重做。先釐清錯誤點：是授權沒更新？是服務沒起來？是網路擋住？還是權限格式錯？
第六章：如果你卡在「安全群組或網路」——先讓連線路徑存在
很多人其實不是 Key Pair 丟了才無法登入，而是安全群組只允許特定 IP、或你換了網路導致來源 IP 不在允許清單中。此時你即使有正確私鑰也連不上。
要判斷是什麼原因，可以用以下順序縮小範圍：
- 從你目前的來源 IP測試是否能連到 instance 的 SSH 端口（例如 22 或實際設定的端口）。
- 檢查該 instance 的 Security Group inbound 規則是否允許你的 IP 或允許範圍。
- 確認是否有 NACL、路由表、或防火牆（如 UFW / firewalld）阻擋。
如果你連 SSH 入口都不存在，後續的「改金鑰」再好也只是徒勞。所以在救援流程之前，至少要確認網路層面有機會到達。
第七章：如何確保改完就能登回去——驗證清單
當你完成授權材料更新後，建議你做一次完整驗證，而不是只試一次就算。
1. 授權材料是否正確生效
- authorized_keys 的內容是否包含你新 Key Pair 的公鑰。
- 目標用戶是否正確。
- 權限是否正確（SSH 對權限非常敏感）。
2. SSH 服務是否啟用、配置是否允許金鑰登入
- sshd 是否在運行（systemctl status sshd / ssh 或等效）。
- /etc/ssh/sshd_config 中是否允許 PubkeyAuthentication。
- 若你曾經改過登入方式，確認 PermitRootLogin、PasswordAuthentication 的值符合你的登入策略。
3. 網路與安全群組
- Inbound 規則是否允許你現在的來源 IP。
- 是否有安全限制如僅允許特定 VPC/子網。
第八章：資安與風險——救援不是終點，後續要做的事更重要
當你成功登入後，請把「救援」當成事件處理流程的開端，而不是結束。
- 立即更新所有你實際使用的登入金鑰：確保只有你現在持有的私鑰對應的公鑰在 authorized_keys。
- 清理殘留的舊金鑰：如果你知道舊私鑰不在了，也可以將其對應的公鑰從 authorized_keys 移除（至少不要保留不必要的授權）。
- 啟用或加強系統層的登入防護：例如限制允許的來源 IP、關閉不必要的登入帳號、使用 Fail2ban 或防暴力設定（視你的環境）。
- 考慮啟用 SSM：未來再遇到私鑰遺失、或要快速介入，SSM 可以大幅降低停機與救援成本。
更關鍵的是：你要把「能重回機器」的能力建立在可維運的流程上，而不是依賴某一把私鑰存不存在。
第九章：常見問題（用更直接的方式回答你可能在想的事）
Q1：我能不能直接在 AWS 把密碼重置？
如果你的 EC2 以 SSH Key Pair 為主，那 AWS 並不提供像「重設密碼」那樣的一鍵功能讓你繞過 Key Pair。最可靠的方式是更新 authorized_keys 或修改系統登入設定，讓你用新的憑證可以通過驗證。
Q2：我把 instance 的 Key Pair 欄位改成新的，是不是就好了？
不一定。很多時候，instance 磁碟內的授權材料不會自動改寫。你需要確保 authorized_keys 實際更新，否則看似更新了但登入仍失敗。
Q3：我用的是 Windows EC2 呢？
Windows 的登入與解鎖流程和 Linux 不同。你可能需要透過 Windows 驗證機制、EC2 解鎖管理或其他管理方式。這篇文章以 Key Pair 遺失導向的 Linux 救援為主；若你告訴我你的作業系統與登入方式，我可以再把步驟整理成適用的版本。
Q4：我是否可以只靠「新建 Key Pair」就不動磁碟？
若你的系統有自動化機制或你之前有可觸及的管理通道（例如 SSM），你可能不需要動磁碟；但在最典型的「完全無法登入且沒有 SSM」情況下，改磁碟並更新 authorized_keys 通常才是穩妥方案。
第十章：把它變成你下次不會再卡住的流程
私鑰丟失這種事，通常不是一次偶發，而是「管理方式」沒有被制度化。救援能解當下的問題，但長期你需要降低再發風險。
我建議至少做到三件事：
- AWS認證帳號 私鑰保存與備份流程：把私鑰存放在受控的密鑰管理器或至少是加密的安全位置，並確保團隊共享的流程清楚。
- 啟用 SSM：讓未來可以用 Session Manager 介入，不必綁死在單一 SSH 私鑰上。
- 權限最小化與登入監控：保留必要登入方式，並記錄登入嘗試。當你之後又遇到類似事件，排查會更快。
結語：真正的重置，是讓你重新取得控制權
標題說「AWS EC2 密鑰丟失怎麼重置密碼」，但實際要解的是「你失去驗證能力」。在 EC2 上最有效的做法通常不是去追憶舊密鑰，而是用你能掌控的通道改回登入授權。若你有 SSM，就用 Session Manager 更新 authorized_keys；若沒有，就透過掛載磁碟的救援方式，把新的公鑰寫回正確的用戶目錄，並檢查權限與網路規則。
AWS認證帳號 只要你依序做「狀況釐清 → 取得系統可控能力 → 更新授權材料 → 驗證網路與 SSH 設定 → 清理與加強資安」，就能把這次的挫折轉成可複用的救援流程。下次就算私鑰又出問題，你也知道該往哪條路走。
