GCP帳號開戶 GCP實例重置Root密碼與開啟Password傳統密碼登錄詳細步驟
第一章：先把目標說清楚
在 GCP 上處理「Root 密碼重置」與「允許傳統密碼登錄」，你其實是在做兩件彼此相關但可以分開的事：第一件是讓你能用正確的憑證登入；第二件是讓系統真的允許用密碼登入，而不是只放行金鑰或乾脆拒絕密碼驗證。
很多人遇到的是同一類狀況：不知道 root 密碼、或者忘記了自己之前把 SSH 設定成只允許公鑰，現在想用密碼方式快速進去排查。要做到穩妥，建議你按順序來：先重置密碼，確認能登入；再開啟 password 驗證，確保遠端連線的路徑通得過。
下面以 Compute Engine 的 Linux 實例為例，步驟盡量用「你在畫面上/命令行上可以照做」的方式寫。不同發行版（Debian/Ubuntu/CentOS/RHEL/自帶映像）細節會有差異，但大方向一致。
第二章：重置 Root 密碼前的準備工作
確認你有權限操作實例
重置密碼、修改 SSH 設定都需要對目標實例具備足夠權限。通常你至少要能在 GCP Console 看到該 Compute Engine 實例，並具備執行「串行控制台」或「編輯啟動參數」的權限。若你是團隊成員，務必先確認角色（例如 Compute Admin/Project Editor 等）夠不夠。
GCP帳號開戶 你可以先做一個簡單自查：能不能開啟 Console -> Compute Engine -> VM 實例列表，並點進目標 VM 的「詳細資訊」頁？能否看到啟動日誌（Serial port / Logs）？如果這些都看不到，就別急著操作，先讓權限到位。
確認 VM 的地區、機器類型與作業系統
重置密碼通常不依賴機器類型，但依賴作業系統提供的工具與檔案路徑。你要知道你是 Ubuntu/Debian 還是 CentOS/RHEL 或其他衍生，因為：
- ssh 設定檔位置與目錄常見是
/etc/ssh/sshd_config，但有些系統會額外引入sshd_config.d片段。 - 某些系統的預設帳號、root 互動方式（例如是否允許直接 root 登入）可能不同。
- 重置密碼的工具可能是
passwd、grub相關流程，或是使用 GCP 提供的特定機制。
你可以在 VM 詳細資訊頁查看「映像（Image）」或「作業系統」。如果映像來源是自訂鏡像，也要特別小心：可能沒有標準的救援流程。
GCP帳號開戶 思考「要不要先改密碼」還是「先開啟密碼登入」
實務上建議是：先重置 root 密碼，然後再開啟密碼登入。原因很直觀：你不確定密碼時去開啟密碼登入，反而會增加安全風險與排查難度。先把「能登入」做到，再做「允許密碼認證」的設定。
第三章：重置 Root 密碼（兩種常見做法）
下面給你兩條路：一條偏向「透過救援/串行控制台進入」，另一條偏向「透過啟動流程與救援模式修改檔案或重新設定」。你可以依你的 VM 與權限情況選擇。
做法一：使用串行控制台 + 進入救援環境重設密碼
串行控制台通常是最直接、最通用的選項。前提是：你的映像支援並且串行輸出可用。
-
在 GCP Console 打開 Compute Engine -> VM 實例。
-
點進目標 VM。
-
在「連線（Connections）」或「串行端口（Serial console）」相關選項中，啟用/開啟串行控制台。（有些帳戶預設可用，有些要你先啟用。）
- GCP帳號開戶
重新啟動 VM，等待你在串行控制台看到 Linux 的啟動訊息。
-
若需要進入救援模式：根據發行版，你可能會在開機選單看到進階選項或救援模式入口。有的系統會要求你在開機時按鍵（此時串行控制台可能支援按鍵輸入）。
-
進入救援 shell 後，掛載原系統分區（如果救援環境預設未掛載）。你可以先確認磁碟分區，例如以
lsblk、blkid找出根分區。 -
掛載根分區後切換到對應路徑，再執行密碼重置：
chroot /mnt passwd root依提示輸入新密碼與確認。
-
退出 chroot，卸載分區並重啟：
exit reboot
這個做法的關鍵在於：你要能正確掛載原系統，並且確保 chroot 進到真正的根目錄。若你掛錯分區，可能會重置到不存在或未被系統使用的環境，結果你登入還是會失敗。
做法二：使用啟動參數/救援盤修改密碼（適用於部分映像）
有些映像或環境在開機時可透過啟動選單進入單使用者模式（single-user / recovery），或利用 root shell 的方式繞過登入流程。具體操作會因為 GRUB 配置而不同，但概念相似：
-
重啟 VM，打開串行控制台或互動式主控台（若可用）。
-
在 GRUB 選單出現時選擇「進階選項」或「recovery mode」。
-
進入 rescue shell 後，確認系統分區並掛載。
-
執行密碼重置（同樣是
chroot+passwd root）。 -
重啟回正常模式，進行登入驗證。
若你在 GRUB 看不到選單或無法互動，可能是映像鎖定了互動流程，這時更建議用做法一。
重置完成後的第一個檢查：你到底能不能用 root 密碼登入
重置完密碼後，先做「目標最小可用驗證」。也就是：在你準備開啟 password 登錄之前，先確認系統是否允許 root 密碼登入。
你可以嘗試在本機用 SSH：
ssh root@你的外部IP
如果系統還是拒絕密碼（例如提示 Authentication failed 或要求你使用金鑰），就意味著第二件事要做：開啟傳統密碼登錄。
第四章：開啟 SSH 傳統密碼登入（Password Authentication）
開啟傳統密碼登錄，核心在於讓 sshd 的設定允許 PasswordAuthentication yes，並確保其他相關設定（例如 PermitRootLogin）不會擋掉。
在系統內確認 sshd 正在使用的設定檔
先進到你的系統。你可以用已存在的金鑰登入（如果還有），或在重置密碼後用新密碼登入。
登入後，檢查 sshd 狀態：
sudo systemctl status ssh
sudo systemctl status sshd
然後找主設定檔：
- 通常是
/etc/ssh/sshd_config - 有些系統有包含片段：
/etc/ssh/sshd_config.d/*.conf
你可以直接查看主檔與關鍵字：
sudo grep -nE 'PasswordAuthentication|PermitRootLogin|KbdInteractiveAuthentication|ChallengeResponseAuthentication' /etc/ssh/sshd_config
如果你看到有 Include 之類的行，記得也要檢查 include 的子檔，因為最後實際生效的設定可能在子檔。
修改關鍵設定：允許密碼驗證與必要時允許 root
在 /etc/ssh/sshd_config（或相關 include 檔）中，找到並確保以下項目符合你的需求。
至少要有：
PasswordAuthentication yes
如果你想用 root 帳號密碼登入，還需要：
PermitRootLogin yes
有些安全預設會寫：
PermitRootLogin prohibit-password
這會讓 root 的密碼登入被拒絕，只允許金鑰或其他方式。你要改成 yes（或你可用更保守的方式：先允許一般用戶密碼登入，再用 sudo 切到 root）。
另外你也可能遇到：
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
這通常與密碼驗證不是同一條，但在某些環境可能造成登入方式不符合你的預期。你不必全改，只要確保密碼路徑可通過即可。
檢查配置沒有語法錯誤
修改設定後，務必先做一次語法檢查：
sudo sshd -t
如果沒有輸出且返回成功，通常表示設定語法沒問題。
重啟 sshd 讓設定生效
執行：
sudo systemctl restart ssh
或：
sudo systemctl restart sshd
依你的系統服務名稱而定。
在本地端再測一次：用密碼登入
現在用新密碼嘗試：
ssh root@你的外部IP
如果成功，你就完成了核心目標。
如果仍失敗，別急著一直調設定，先做下一章的「常見阻擋清單」，把問題定位到 GCP 層還是系統層。
第五章：連不上或登入失敗的常見原因與排查
很多人以為密碼驗證沒開成功，其實是被防火牆、網路標籤、或 root 登入限制擋住。排查建議採取「由外到內」的順序。
第一層：GCP 防火牆（Firewall）是否放行 TCP 22
你要確認入站規則允許 SSH。Compute Engine 的防火牆常用規則是「允許 tcp:22」。如果你沒有外部 IP 或沒有開相應規則，連線會根本到不了 sshd。
你可以在 GCP Console 檢查該 VM 所屬的 network 與防火牆規則，尤其看這幾件事：
- 目標（Targets）是否包含該 VM（透過網路標籤/服務帳戶等）。
- 來源（Source ranges）是否允許你的 IP。
- 規則是否生效且未被更高優先級的規則覆蓋。
- 是否只允許內部流量或特定來源。
若你只能測試，且你有公網測試工具，能連上 TCP 22 才算第一關過了。
第二層：VM 是否真的有可用的對外 IP
GCP帳號開戶 某些情況 VM 只有內部 IP，你在外網直接 ssh 會失敗。你需要：
- 有外部 IP，或
- 透過 VPN/Interconnect/Private Service Connect 之類路徑，或
- 使用 IAP（Identity-Aware Proxy）進行安全連線。
你不必把所有路徑都搞懂，但至少要確認你測試方式與網路拓撲一致。
第三層：sshd 設定仍然拒絕 root 密碼
常見情況是你開了 PasswordAuthentication yes，但 PermitRootLogin 還是拒絕密碼。建議你回到系統內再次檢查：
sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin'
GCP帳號開戶 這個指令會輸出 sshd 實際生效的參數。比起只看設定檔內容，它能幫你快速判斷「到底 sshd 最終怎麼想」。
第四層：密碼帳號鎖定或過期
有時候你確實改了密碼，但帳號狀態仍導致登入失敗。你可以檢查 root 的狀態：
sudo passwd -S root
如果顯示 locked 或其他異常，就需要把 root 解鎖/重設（不同系統命令略有差異，但原理是恢復可登入狀態）。
第五層：你改的其實不是正在運行的那套設定（include 片段覆蓋）
只改了 /etc/ssh/sshd_config，但系統可能從 include 檔覆蓋同名設定，導致結果不生效。這正是為什麼上面我建議用 sshd -T 來確認實際生效值。
第六章：安全性要講清楚：為什麼不建議長期開啟密碼登入
「開啟傳統密碼登錄」能讓你快速恢復操作，但也同時提高被暴力破解的風險。即使你只打算短時間使用，也建議你至少做到以下基本安全：
- 使用強密碼，避免常見字典或弱密碼。
- 限制防火牆來源 IP，至少不要對全世界開放。
- 如果可行，先讓一般使用者用密碼登入，再用 sudo 切到 root；或只在臨時階段允許 root。
- 登入完成後，把
PasswordAuthentication改回原本策略（通常是no），恢復只允許公鑰。
你把設定改完就關掉，才是最務實的做法。很多事故不是來自一次操作失誤，而是忘記把風險留在那裡。
第七章：把流程收斂成可重複的操作清單
如果你希望每次都能順利完成，我建議你把整件事固定成一個順序：
流程 A：忘記密碼 + 想用 root 密碼登入
- 在 GCP Console 打開目標 VM 並啟用/確認串行控制台可用。
- 重啟 VM，進入救援/單使用者/救援 shell。
- 掛載根分區，
chroot進入原系統。 - 執行
passwd root設定新密碼。 - 重啟回正常模式，先測登入（可能先會失敗）。
- 進入系統後修改
/etc/ssh/sshd_config（或 include 檔）：PasswordAuthentication yes。 - 若要 root 密碼登入，確認
PermitRootLogin yes。 - 執行
sshd -t檢查語法，重啟 sshd。 - 用
sshd -T確認最終生效設定。 - GCP帳號開戶 最後在 GCP 防火牆確認放行 TCP 22（限制來源）。
- 登入成功後，依需要在完成維運後恢復密碼登入策略。
流程 B：你不一定要 root 密碼，只要能進去查資料
更安全也更常見的做法是：只允許一般用戶密碼登入，然後用 sudo 取得 root 權限。
- 重置你要登入的那個帳號密碼（不一定是 root）。
- 在 sshd 設定中只打開
PasswordAuthentication yes，但把PermitRootLogin保持為禁止密碼。 - 確認 sudo 權限允許你執行需要的管理操作。
這樣可以降低暴露範圍，也更符合很多團隊的安全習慣。
第八章：你可以用這些問題快速定位卡點
- GCP帳號開戶 連 SSH 連不上？——先看 GCP 防火牆與外部 IP。
- 能連到但一直密碼失敗？——看 sshd 設定（PasswordAuthentication / PermitRootLogin）與帳號狀態（鎖定/過期）。
- 改了設定但沒效果？——檢查 include 覆蓋，並用
sshd -T確認實際參數。 - 重置完仍不行？——可能是你 chroot 掛錯分區或重置到錯誤環境。
- GCP帳號開戶 希望暫時開密碼登入但又怕風險？——限定來源 IP，完成後立刻關回。
GCP帳號開戶 結語：把控制權拿回來，但別把風險留下
GCP 上重置 Root 密碼與開啟傳統密碼登錄，本質是「先恢復登入能力，再放行登入途徑」。你只要按順序做：救援重置密碼、確認能登入、再調整 sshd 的密碼認證與 root 登入限制，最後再把 GCP 防火牆的網路路徑補齊，就能把問題逐層收斂。
更重要的是：密碼登入不該成為常態。你可以把它當成臨時急救工具，用完就收回設定。當你的系統恢復到只允許公鑰或更嚴格的策略，整體的可用性與安全性才會一起回到正確軌道。
