简介：面向运维与网络安全从业者的一份F5 BIG-IP密码恢复专题文档，聚焦管理员遗忘密码后如何通过控制台完成重置，内容覆盖Ver9.0、10.0、11.0等版本，适合具备基础网络设备操作经验、需要应急处理ADC登录故障的读者参考。压缩包共1个文件，为docx格式的操作说明，体积约92KB，轻量便于随取随查。该文档已有537人学习，说明在设备运维与密码恢复场景中具有一定关注度。正文围绕控制台连接、终端参数设置、TCL与tmsh命令使用、root及admin密码修改、配置保存与重启生效等环节展开，并附F5官方解决方案链接，便于读者核对原理与操作边界；同时保留版本适用说明和测试背景，可帮助读者梳理排错路径、理解命令作用，降低误操作风险。

1. 一台 F5 摆在机房里，密码只存在离职同事的脑子里

我见过最尴尬的一次故障，不是硬件坏了，也不是链路断了，而是一台 F5 BIG-IP 蹲在机柜里，Web UI 提示密码错误，SSH 提示认证失败，而知道密码的那位同事已经离职三个月了。交接文档里写着“密码见 Excel”，Excel 在一台已经重装过系统的笔记本上。整台设备的密码恢复，最后只剩下一根 console 线、一个 19200 的波特率，和一堆没人敢按的重启按钮。这篇讲的就是 F5 密码恢复这件事：在 BIG-IP 9.0、10.0、11.0 三个版本上，从串口连上去、拿到能敲命令的 shell、把 root 和 admin 的密码改掉、把配置存下来、再重启验证，全程可复现。新手能照着一步步走，熟手能对得上我在每一步的判断依据，以及那些改完密码重启后又被“打回原形”的坑。

2. 先分清卡在哪一层：F5 密码恢复的三条路径

动手之前最该做的不是插线，而是先判断自己手上还剩什么。F5 BIG-IP 的密码恢复不是一招通吃，你手上剩的资源决定了走哪条路，走错路轻则白折腾一小时，重则把一台还在跑业务的设备搞进不一致状态。我给这套判断分了三档，每一档的处置方式和风险完全不同。

2.1 三种“密码没了”的场景，处置路径完全不同

第一种，Web UI 的 admin 密码忘了，但 root 还能 SSH 上去。这是最轻的一档，root 在 F5 体系里是底层账号，能直接改 admin 的认证信息，不需要重启，也不影响在线业务。第二种，admin 和 root 全忘了，但你有物理接触或者带外 console 权限。这是最常见的一档，也是这篇的重点，必须走串口维护通道。第三种，两个密码都没了，人也进不了机房，只有一条网络可达。这一档基本没救，除非设备是 HA 双机、对端还能登进去做配置同步覆盖，否则只能走重装或者返厂。

判断依据其实只有一句话：console 是唯一一条在完整认证栈加载之前就能给你 shell 的通道。Web UI 和 SSH 都跑在认证之后，密码不对就是不对，没有任何绕过空间。而串口在 boot 阶段就挂上了，维护 shell 不经过完整的用户认证流程，这也是所有厂商把“最后一道救援通道”放在串口上的原因。

2.2 三条管理入口的失效顺序，决定了你先试哪个

一台 BIG-IP 通常有三条管理入口：HTTPS 的 443、SSH 的 22、以及面板上的 console 口。很多人上来就试 SSH，试不通再试 Web UI，两个都不通才开始慌。我的习惯是反过来：先确认 SSH 通不通，因为 SSH 通一般意味着 root 或 admin 至少有一个还能用；SSH 不通再确认 Web UI，因为 Web UI 只认管理角色账号，root 未必能登；两个都不通，直接上 console，不要在网络上浪费时间。

这里有个容易忽略的版本差异：11.x 之后，root 默认不允许直接 SSH 登录，能 SSH 的只有具备管理权限的账号。所以你在 11.x 上看到“SSH 拒绝”不代表 root 密码错了，可能只是策略不允许。反过来在 9.x 和 10.x 上，root 直接 SSH 是很常见的。这个差异会直接影响你对“密码到底错没错”的判断，别在 11.x 上因为 SSH 被拒就判定 root 密码丢失。

console 这条路的物理前提是那根线。F5 的 console 口是 RJ45 形态，但用的是 rollover 线序，不是普通直通网线，也不是交叉线。我见过有人拿一根普通跳线插上去，终端一片安静，以为设备挂了，换根 Cisco 风格的 console 线立刻就出提示符了。线序这件事没有玄学，就是不能凑合。

2.3 9.0 / 10.0 / 11.0 的版本差异对照

原文明确写了这套方法在 9.0、10.0、11.0 上都实测通过，但三个版本的 shell 环境和命令习惯并不一样，照着同一套敲未必处处顺手。下面这张表是我按实际差异整理的对照，重点看“默认落在哪个 shell”和“保存配置的写法”两列。

表里最后一行的差异值得单拎出来说。11.x 开始对密码强度有校验，你随手敲一个admin123很可能被直接拒绝，而且报错信息不一定直白，看起来像是命令没生效。遇到这种情况先别怀疑命令写错了，换个满足长度和字符组合要求的密码再试一次，大概率就过了。

另外，9.x 上 tmsh 覆盖的命令集比 11.x 窄，原文给的modify auth password在 9.0 上实测可用，但如果某些更早的小版本上这条不认，退回到系统层的passwd root也是常见做法。判断依据很简单：敲完命令看它返回的是提示输入新密码，还是返回一段 usage 说明。前者说明命令被识别了，后者说明你进错了 shell 或者这条命令在这个版本上不存在。

3. 动手前的准备：串口参数、版本确认和一次老实备份

真正让密码恢复翻车的，往往不是改密命令本身，而是前面这几步没做扎实。串口参数差一位就是满屏乱码，版本没确认就照着 11.x 的写法往 9.x 上套，备份没做导致改完发现业务配置对不上，这些都比“命令记错”更常见。这一章讲的就是上电之前该确认的三件事。

3.1 19200 8N1：串口参数每一位都要对

F5 BIG-IP 的 console 默认速率是 19200，这个数字和大多数网络设备默认的 9600 不一样，是新手最容易踩的第一个坑。完整的参数是 19200 波特率、8 数据位、无校验、1 停止位、无流控。流控这一项特别容易被忽略，SecureCRT 和 PuTTY 默认可能开着 RTS/CTS，结果就是你看着提示符在那儿，敲键盘却毫无反应，或者敲一个字符出来两个。

三种常见终端软件的配置位置不太一样，但参数是同一套：

连上之后先敲两三次回车。正常情况下应该出现登录提示符或者直接的 shell 提示符；如果满屏是规律的乱码方块，八成是波特率不对，先切 9600 试一下，再切回 19200；如果完全没反应，先怀疑线序，再怀疑 USB 转串口驱动，最后才怀疑设备。这个排查顺序能省掉大量瞎猜的时间。

提示：USB 转串口线在部分系统上会枚举成两个 COM 口，选错那个就是死活没输出。设备管理器里看哪一个在插拔时有变化，用那个。

3.2 上线前先确认版本，以及能不能备份

拿到 shell 之后，第一件事不是改密码，是确认版本。版本决定了你后面用哪套保存命令，也决定了密码策略会不会拦你。常见做法是先看系统版本，再决定命令写法。原文覆盖的是 9.0、10.0、11.0 三个大版本，如果你的设备是 12.x 甚至更新，命令大体还在，但周边行为可能已经变了，这时候更该先确认再动手。

能进到 shell 就说明你有机会做备份。F5 的配置最终落在/config下面，能把这几个文件先导出来或者至少确认它们的存在，后面就算改出问题也有对照。我在动任何认证相关配置之前，一定会先确认三件事：当前配置能不能正常读出来、当前有没有 HA 对端、当前设备是不是在跑生产流量。这三件事里任何一件是“不确定”，我都会先停下来搞清楚。

原因很直接：密码恢复本身是个小操作，但它会触发重启，重启会触发配置加载，配置加载在 HA 环境下会触发同步。一个改密动作，最后可能演变成两台设备配置互相覆盖。这不是危言耸听，是这类设备上真实发生过的连锁反应。

3.3 授权边界：什么情况下不该动

这一段必须说清楚。密码恢复的所有操作，前提是设备归你管、或者你有明确的书面授权。console 口拿到的是设备的最高权限，改 root 密码、改 admin 密码、重启设备，每一步都可能影响在线业务。没有授权就动，性质完全不一样。

有授权也要评估时机。设备在跑核心业务、没有维护窗口、没有 HA 兜底的情况下，重启这一步的风险远大于“再等两个小时”。我的判断标准是：如果这台设备重启会导致业务中断且没有备用路径，那就把操作推到维护窗口，不要图省事。改密命令本身是秒级的，但重启不是。

4. 完整复现：从串口登录到改密重启的九步

前面铺垫完了，这一章是真正可以照着敲的部分。整个流程在原文里是九步：连 console、输错密码保持连接、进到能执行命令的环境、切 tclsh、改 root、改 admin、保存配置、退出、重启。我按实际执行的顺序重新组织，并且把每一步“为什么这么敲”说清楚，方便你在不同版本上做适配。

4.1 第一步到第三步：进到那个能敲 tmsh 的 shell

串口连上、参数对齐之后，你会看到登录提示。这一步的关键在原文里写得很直白：输错密码，但不要关闭连接。原因是设备在认证失败之后，部分版本会把你放进一个受限的维护环境，而不是直接踢掉。这个环境就是你后面所有操作的落点。很多人输错一次看到拒绝提示就把终端关了重来，反而永远进不去。

进到维护环境之后，先确认自己在哪儿。敲tmsh回车，如果直接进了 tmsh 的提示符，说明你已经在能执行管理命令的层；如果提示找不到命令，说明你还在一个更底层的 shell 里，需要先确认路径。原文在这一步给的做法是先跑一段抓包工具、再进tclsh，我的习惯是：抓包那一步除非要留证据，否则跳过，它不改变流程，只是多产出一个抓包文件；而tclsh这一步要特别注意，因为它是 TCL 解释器，不是 shell。

# 确认当前落在哪个环境，避免在错误的 shell 里敲管理命令 tmsh # 能进提示符说明管理命令行可用 echo $SHELL # 看当前 shell 类型 which tmsh # 确认 tmsh 的路径，后面 exec 时会用到

这三条命令的意义在于定位，不在于执行。tmsh能进说明你离成功只差两条命令；进不去说明你还在更底层的环境，得先exit或者换路径。which tmsh拿到绝对路径之后，即使你在tclsh里，也能用exec把命令包一层执行，这是原文没写但实际很好用的一招。

4.2 第四步到第六步：root 和 admin 的两种改法

改 root 密码用的是tmsh modify auth password root。敲下去之后系统会提示输入新密码，再输一次确认。这条命令在 9.0、10.0、11.0 上都实测通过，是整套流程里最稳的一步。要注意的是，11.x 上如果新密码不满足复杂度策略，这里会直接失败，表现可能是提示重新输入，也可能是返回一段策略说明。遇到就换个强一点的密码，别在原地反复试同一个。

# 改 root 密码，执行后会交互式提示输入两次新密码 tmsh modify auth password root # 改 admin 密码，两种写法，按版本和习惯选一种 tmsh modify auth user admin prompt-for-password tmsh modify auth password admin

两条改 admin 的命令区别在于作用对象。modify auth user admin prompt-for-password是明确指定“用户 admin”然后交互式要密码，语义更清晰，在有多管理员账号的环境里不容易误伤；modify auth password admin是直接对 admin 这个账号的密码下手，写法更短，原文标注两种都可用。我在实际操作里优先用前者，因为它的意图更明确，出问题时也更容易判断是哪一步错了。

顺序上建议先 root 后 admin。原因很实际：root 是底层账号，改完之后你至少有一个确定能用的凭据；admin 是管理面账号，改它的时候如果碰到密码策略或者角色限制，你已经有一个可回退的入口。反过来先改 admin，万一中途出问题又没保存，你手上可能一个可用密码都没有。

注意：改密码的时候不要同时在另一个会话里挂着旧的 admin 登录。改完之后旧会话的凭据还在缓存里，容易出现“新密码登不上、旧会话还能用”的错觉，让人误判改密失败。

4.3 第七步到第九步：保存、退出、重启，顺序不能乱

保存配置这一步是整套流程里最容易被轻视、后果最严重的一步。原文给了两种写法：save /sys config和save sys config，11.x 上更规范的是tmsh save sys config。这三种写法的目标是一致的，把当前内存里的配置落到持久化存储里。不保存就重启，等于白改，这是这条流程里最经典的一次翻车。

# 保存配置，三种写法按版本选 save /sys config # 9.x / 10.x 常见写法 save sys config # 同上，空格差异 tmsh save sys config # 11.x 更规范 # 退出当前环境，回到上一层 quit # 重启设备，让新的认证信息在完整启动流程里生效 reboot

reboot这一步要留出足够时间。BIG-IP 的启动不是几秒钟的事，从敲下命令到管理面重新可用，中间会经历一段完全失联的窗口。这期间串口上会滚动大量启动日志，别因为看到一堆报错就慌，很多是正常的服务启动顺序输出。判断是否启动完成，看的是最终有没有回到登录提示，而不是中间某一行看起来像错误的日志。

重启完成后，用新密码走一遍 SSH 和 Web UI。两个都通，才算这套流程真正闭环。只验证一个的话，很可能出现“SSH 通了但 Web UI 还认旧密码”的情况，原因通常是浏览器缓存了旧会话，换个无痕窗口再试一次就能排除。

5. 五个翻车现场：从满屏乱码到重启后密码回滚

这套流程我在不同版本上走过很多次，成功的路径基本一致，失败的花样却很多。下面这五条是我记录过的真实翻车点，每条都按“看到什么现象、根因在哪、怎么解决”写，你对号入座基本能定位到自己的问题。

5.1 现象：串口满屏乱码，敲什么都没反应

原因：波特率不匹配是最常见的，F5 默认 19200 而很多设备是 9600，终端软件沿用上次会话的配置就会错位。第二常见的是线序不对，用了普通直通网线而不是 rollover 线。第三是流控没关，导致输入被吞。

解决：先把终端参数逐项对齐 19200 / 8 / None / 1 / 无流控，再敲回车看输出；仍然乱码就换线，用确认过线序的 console 线；换线还不行，检查 USB 转串口驱动和 COM 口编号。三步走完基本能解决，不要在乱码状态下瞎敲命令，你不知道自己敲进去的东西被解释成了什么。

5.2 现象：在 tclsh 里敲 tmsh 命令，提示命令不存在

原因：tclsh是 TCL 解释器，不是 shell。它只认 TCL 语法，不认系统命令。原文的流程里进了 tclsh 之后直接敲 tmsh 命令，在某些版本上能过是因为环境变量和路径恰好对，但在另外一些版本上就会报“invalid command name”这类错误。

解决：两个办法。一是先exit退回上一层 shell，再敲 tmsh 命令，这是最稳的；二是留在 tclsh 里，用exec把命令包一层，比如exec tmsh modify auth password root，让 TCL 去调用系统命令。判断依据是看报错内容：说“找不到命令”是环境问题，说“参数错误”才是命令本身写错了。

5.3 现象：改完密码重启，登录还是提示旧密码错误

原因：配置没保存。改密命令改的是运行态，没执行保存就直接重启，设备从持久化配置里重新加载，认证信息回到修改前。这是最高频的一次翻车，也是最冤枉的一次。

解决：改完密码之后立刻保存，别等到重启前才想起来。保存命令按版本选save sys config或tmsh save sys config，执行后确认没有报错再往下走。已经翻车的话，重新走一遍流程，这次把保存放在改密和重启之间，中间不做别的事。

5.4 现象：HA 双机环境，一台改完重启，配置被对端覆盖

原因：设备处于配置同步状态，你在一台上改的内容，重启后被对端的配置同步过来覆盖掉。表现就是改完密码重启，密码又不对了，而且日志里能看到同步记录。

解决：动之前先确认有没有 HA 对端。有的话，要么把两台都按同样流程改掉，要么先把同步关系断开再操作，改完再恢复。判断依据是看配置里有没有配置同步组，以及当前设备是主还是备。这一步没有捷径，只能提前确认。

5.5 现象：新密码设置时报错，反复要求重新输入

原因：密码复杂度策略。11.x 开始对密码强度有校验，长度不够、字符组合太简单都会被拒，而且提示不一定直白地告诉你“密码太弱”。

解决：换一个满足长度和字符类型组合的密码再试，别在原地重复输同一个。判断依据是看报错出现的时机：如果是在你输完第一次之后立刻返回，基本就是策略拦截；如果是在两次输入不一致时才报，那是确认环节的问题。

6. 收尾动作：改完密码之后我必做的三件事

密码改完、设备重启完、SSH 能登、Web UI 能进，很多人到这儿就收工了。我一般会再花十分钟做三件事，因为这三件事决定了这次操作是“解决了问题”还是“埋了个雷”。

第一件，用新密码把两条管理入口各走一遍完整流程。SSH 登录后执行一条只读命令确认会话正常，Web UI 用无痕窗口登录确认能进到主界面。只测一条的话，很可能漏掉另一条通道上的缓存或策略问题，等到下次真要用的时候才发现，那时候又没有维护窗口了。

第二件，确认配置真的落盘了。不是看保存命令有没有返回成功，而是重启之后再进一次 shell，确认认证信息是新的。这一步看着多余，实际上是把“保存成功”和“生效成功”两件事分开验证。我吃过一次亏，保存命令返回正常，但设备重启后加载的是另一份配置，密码回到旧值，当时以为是自己记错了密码，排查了很久才定位到配置加载路径。

第三件，把新密码写进该写的地方，并且确认交接链路。这一条听起来不像技术活，但它决定了半年后会不会有人再走一遍今天这套流程。密码放在只有一个人知道的地方，等于没放。

回过头看，这套流程里真正难的不是那几条命令，命令本身照着敲就行，难的是判断“我现在卡在哪一层”和“我这一步做完会不会被后面的动作覆盖掉”。串口参数、版本差异、保存时机、HA 同步，这四个点任何一个没想清楚，都会让一次十分钟的操作变成一整晚的排查。从那以后我每次动认证相关的配置，都会强制自己先走一遍“确认版本、确认备份、确认 HA、改密后立刻保存”这四个动作，一个都不跳。这套习惯比记住任何一条命令都值钱。希望帮到你。

本文还有配套的精品资源，点击获取