Cisco 密碼恢復沒有一套能跨 Catalyst、IOS、IOS XE 與路由器通用的流程。完整型號、系統版本、bootloader，以及是否停用 password recovery，都會改變操作方式與資料能否保留；未核對當版官方文件前不要套用網路上的 ROMMON 或 config-register 指令。
密碼從來不是被「破解」出來的
先講一個觀念，想通了，後面每個步驟都會變得合理：交換器的密碼回復，從頭到尾沒有任何一步在「破解」密碼。enable secret 存進設定檔的時候走的是不可逆的雜湊，就算是原廠工程師也還原不出你當初打的那串字。既然破不了，那救的實際是什麼？救的是「開機時先不要載入那份含密碼的設定」。讓系統以空白狀態開機，你自然就落在不需要密碼的特權模式裡，接著再把原本那份設定讀回來、用新密碼把舊的覆寫掉，存檔。整套邏輯是繞過，不是破解。理解這一點，你就會發現：每一種機型的做法看似不同，本質其實一模一樣，差別只在「怎麼讓它這次開機不載入設定」這一步。
為什麼路由器那套搬到交換器上行不通
路由器的 0x2142 玩的是 configuration register，一個十六進位的暫存器數值。把它從常見的 0x2102 改成 0x2142，等於告訴系統開機時跳過 NVRAM 裡的 startup-config。這是路由器獨有的機制，固定式的 Catalyst 交換器根本沒有這顆暫存器可以改，所以 confreg 那一套用在交換器上不是無效，而是根本無從下手。
那交換器怎麼存設定？傳統 IOS 世代（2950、2960、3560 這一代）把設定放在 flash 裡一個叫 config.text 的檔案，救法是進 bootloader 直接對這個檔案動手腳，讓它開機時讀不到。跑 IOS-XE 的 Catalyst 9000 系列（9200、9300、9500）又不一樣，改的是 ROMMON 裡一個環境變數，叫系統這一次開機略過 startup-config。三種機制、三套指令，但剛才說的那個本質：先不載入設定，再把設定讀回來覆寫密碼：三者共用。
動手的前提：你摸得到這台機器
不管哪一套，第一步都是取得合法的實體存取與 Console／OOB 路徑。不過 Console 類型與速率仍要查完整型號手冊，不能把 9600 8N1 套到所有 Catalyst。先確認線材、USB driver、堆疊角色與開機訊息，再依該 family／release 的 recovery guide 操作。機房門禁與操作留痕也要一起顧，因為能接觸 Console 的人通常就有機會改變開機流程。
傳統 IOS 世代：MODE 鈕加 flash_init
2950、2960、3560 這一代固定式交換器沒有 ROMMON 提示可以中斷，靠的是面板上那顆 MODE 鈕。流程是這樣：
- 先把電源拔掉。按住面板左側的 MODE 鈕，同時把電源重新接上，持續壓著不放，大約十幾到二十幾秒，畫面會開始跑出一串訊息。不同機型放開的時機以畫面提示或 SYST 燈號變化為準（常見是燈號由閃爍轉為恆亮的當下），放開後就停在 switch: 提示符。
- 下 flash_init 初始化 flash 檔案系統，接著 load_helper 載入輔助程式，再用 dir flash: 列出檔案（flash 後面那個冒號不能漏）。
- 把設定檔改名讓它失效：rename flash:config.text flash:config.old。這一步只是改名不是刪除，等於順手幫舊設定留了一份備份，開機時系統找不到 config.text，就會以空設定啟動。
- 下 boot 重開。跳出初始設定精靈時輸入 n 略過，這時你人已經在特權模式裡了。
- 把設定救回來：rename flash:config.old flash:config.text 改回原名，再 copy flash:config.text system:running-config 把原設定讀進運行組態。這時 VLAN、埠口、路由該有的全回來了，只差密碼還是舊的。
- 重設 enable secret 跟各 line 的密碼，最後 write memory 存檔收工。
這套做法最大的好處是設定零損失：只有密碼換新，其他原封不動。會出包的地方通常是兩個：一是 MODE 鈕放太早，還沒進到 switch: 就鬆手，只好整個重來；二是省略 load_helper，某些 IOS 版本少了它，dir flash: 會讀不乾淨、後面接著卡住。慢一點、照順序來，這一代其實是三種裡面最單純、最不容易釀成大禍的。
Catalyst 9000（IOS-XE）：ROMMON 設一個略過設定的變數
9200、9300、9500 這一代跑的是 IOS-XE，架構跟傳統 IOS 差很多，密碼回復改走 ROMMON 環境變數。重點是它的「危險係數」比傳統 IOS 高，因為多了一步很容易被跳過、一跳過就出大事的關鍵動作。
- 開機過程中中斷進 ROMMON。這一代通常是送 break 訊號或按 Ctrl-C 中斷開機（部分機型仍可用 MODE 鈕），停在 rommon 提示符。
- 設變數：SWITCH_IGNORE_STARTUP_CFG=1，然後 boot。系統會以空白設定開機。注意：是「略過」不是「刪除」，你的 startup-config 還好端端躺在 flash 裡。
- 開機登入後，第一件事、也是整個流程最關鍵的一步：copy startup-config running-config，把原設定讀回運行組態。這一步絕對不能跳。
- 設定讀回來之後，才動手改 enable secret 跟登入帳密。
- 改完把略過旗標關掉：no system ignore startupconfig switch all，再 copy running-config startup-config 存檔。
- 最後用 show romvar 確認 SWITCH_IGNORE_STARTUP_CFG 已經清乾淨。這步別偷懶，變數沒清掉，下次一重開機又是一台空機。
這一代現場常見最痛的三種失誤，全都跟順序有關：
- 存檔存太早。一登入就急著改密碼、直接存檔，可是這時運行組態是空的，等於拿一份空設定去覆蓋 startup-config，一台核心交換器的 VLAN、埠口、路由瞬間全沒。這是最痛也最常見的一種，痛點就在「copy startup-config running-config 忘了先做」。
- 略過變數忘了清。密碼改好了、當下看起來一切正常，可是 SWITCH_IGNORE_STARTUP_CFG 還掛著，下一次重開機就會再度以空設定啟動：問題被延後，往往在最沒防備的時候（例如某次計畫外的停電復電）才爆出來。
- 把堆疊當單機處理。這點下一段細講，它是 9000 系列翻車的第一名。
堆疊（StackWise）的眉角
如果這是一組堆疊，做法要再多一層心思。先把堆疊裡其他成員全部關機，只留你要操作的那台 active 主機開著，再進 ROMMON。原因是：你在 active 上以空設定開機的期間，若其他成員還活著，standby 會把它手上那份舊設定同步回來，你辛苦做的略過動作等於白費，密碼回復直接失敗。正確順序是：其他成員先斷電、只留 active、完成回復並確認存檔無誤之後，才逐台把成員開回來讓堆疊重新同步。順序顛倒，輕則救不回來，重則被舊狀態把你剛改好的設定又蓋掉。堆疊架構之所以是這一代的翻車重災區，就是因為很多人把它當成一台單機，忽略了背後那套設定同步機制一直在運作。
Password recovery 能不能停用？命令依平台而異
是否能停用密碼回復、命令名稱與忘記密碼後的代價，都依 Catalyst family 與 IOS／IOS XE release 而異。Cat9K 要查當版 system disable password recovery ... 文件；舊 IOS 平台才可能使用 no service password-recovery [strict]。兩套不能混在一起，也不能把某版的行為寫成全系列通則。
未確認完整型號、堆疊角色與版本前，不要下停用或 recovery 指令。部分平台在 recovery 被停用後，bootloader 只會在你接受清除組態時繼續；不是一句「只能 RMA」就能概括。正式環境先取得設定備份、OOB／Console、維護窗與回復計畫，再依該平台官方 guide 操作。
該自己動手，還是該找人？一個工程判斷
把技術細節收起來，講最實際的決策。密碼回復本質上是一次停機操作：重開機那段期間，這台交換器上所有服務都會中斷。它擺在網路的哪一層，決定了這次停機是「一個角落沒網」還是「全公司斷線」。同一套流程，落在不同位置的設備上，風險是天差地遠的。
我自己的準則大致是這樣：
- 可以自己來：接入層的邊緣交換器、單機非堆疊、下班後有明確的維護時間、機型又是熟悉的傳統 IOS。照著文件慢慢做，風險完全可控。
- 建議找熟手：核心層或匯聚層設備、StackWise 堆疊架構、IOS-XE 機型不熟、或設備曾經被設過 no service password-recovery。這幾種情況任何一個小失誤的代價都是全網級的，真的不值得拿公司營運去賭那幾千塊工程費。
不管哪一種，動手前有一個動作不能省：把還撈得到的東西先備份下來。就算現在進不去設備本身，很多資訊仍能透過既有的網管系統、鄰近設備的 CDP／LLDP 對接資訊，或既往留下的組態備份拼湊出來。手上多一份底稿，出事時就多一條退路。救回來之後也別忘了收尾：把新密碼放進公司的密碼管理流程，別再塞在某一個人的腦袋裡。實際上，交換器會忘記密碼，常見不是機器的問題，而是上一個知道密碼的人離職了：這是管理漏洞，不是技術問題，補起流程才是真正治本。
