F5 BIG-IP密码恢复：console单用户模式重置admin/root

简介：面向运维工程师与网络设备管理人员的F5 BIG-IP密码恢复参考文档，聚焦管理员忘记密码后如何通过控制台完成密码重置，适用Ver9.0、10.0、11.0等版本。包内仅含1个docx文件，压缩包约92KB，篇幅精炼，便于在维护现场快速查阅；文档围绕控制台连接参数、root与admin账户密码修改、配置保存及重启生效等环节整理操作记录，并附F5官方解决方案链接供核对。已有537人学习，适合作应急恢复时的案头参考资料，也可用于了解旧版BIG-IP的密码维护思路；阅读时仍需结合官方文档与现网版本谨慎判断。

1. 忘记密码不等于重装：F5 密码破解这条 console 通道还值不值得走

F5 密码破解这件事，说穿了就一句话：只要还能摸到 console 口，admin 密码就丢不了。可真到现场，很多人第一步就卡住：串口连上去满屏乱码，或者好不容易进了单用户模式，命令敲进去却提示不存在。手里这份记录最早是 2014 年落下来的，Ver9.0、10.0、11.0 三个版本都实测过，流程本身不复杂，复杂的是文档里不写的细节：波特率为什么非得是 19200、root 和 admin 到底该改哪个、save的两种写法差在哪、以及原始记录在抄录时把tmsh写成tshark留下的坑。这篇把这些拆开讲，手里有设备物理接触权、或者拿到了运维授权的人，照着能落地；暂时摸不到设备的人，看完至少知道该向谁申请什么权限、要准备哪几样东西，而不是一上来就想着重装系统。

2. 动手之前的三个硬前提：串口参数、账号体系与版本分叉

密码恢复能不能成，八成不取决于命令本身，而取决于动手之前有没有把这三件事确认清楚。我见过太多次翻车，不是命令敲错，是串口线插着却根本不通、或者把 root 的密码改了却跑去 web 界面登录。

2.1 串口这一关：19200 只是五个参数里的一个

BIG-IP 设备的 console 口默认跑在 19200 波特率上，这一点原始记录里写对了，但只写这一条是不够的。串口通信是一组参数共同决定的，缺一个就可能是乱码或者完全无响应。终端软件用超级终端、SecureCRT、PuTTY 都行，配置项对得上才是关键。

物理层还有两个容易被忽略的点。一是线材，不少设备的 console 口是 RJ45 形态，需要专用的 RJ45 转 DB9 或者转 USB 转接线，拿一根普通网线接进去是不通的；二是 COM 口号，USB 转串口线插上以后在设备管理器里会新分配一个 COM 口，SecureCRT 里如果还停在上一次的 COM3，那连的就是另一台设备或者干脆是空的。

提示：接好线之后先别急着重启设备，先在终端里敲两下回车。能看到登录提示符或者光标有回应，说明链路是通的，再往下走；如果一片死寂，先回去查流控和 COM 口，别怀疑设备坏了。

我一般会这么确认：把终端连上，设备当前如果是运行状态，按回车应该能出login as:之类的提示。这一步过了，后面的操作才有意义。如果这一步就出不来，密码恢复的流程根本还没开始，花时间研究后面的命令是白费。

2.2 root 和 admin 是两套账：改错一个等于白干

原始记录里出现了两条不同的改密命令，一条改 root，一条改 admin，很多人看到这里就懵了，干脆两条都敲一遍。其实这两个账号在 BIG-IP 上是两套独立的认证体系，职责完全不同。

root 是底层的 Linux 系统账号，用来登录设备的 shell 层，做一些底层维护；admin 是 TMOS 管理平面的账号，web 管理界面、SSH 管理登录、图形化配置走的都是它。日常运维说「设备密码忘了」，绝大多数指的是 admin，因为大家平时根本不登 root。

这就带来一个很实际的问题：如果你只改了 root，然后跑去 web 界面用 admin 登录，当然还是登不进去，于是会误判成「方法无效」。反过来，只改 admin 而 root 密码依然未知，某些需要落到底层 shell 的排障操作还是做不了。

稳妥的做法是两个都重置一遍，反正命令就两条，成本极低。改完之后心里要清楚：web 界面能不能进，只看 admin；shell 能不能进，只看 root。把这条对应关系记住，后面排查问题时就不会绕圈。

还有一层：这两个账号的密码策略可能不一样，某些版本对 admin 有复杂度和有效期要求，对 root 相对宽松。如果你给 admin 设了一个太简单的密码，命令可能不报错但登录仍然被拒，这时候要去看密码策略而不是怀疑命令。

2.3 9.x 到 11.x 的启动分叉：单用户模式怎么进得去

原始记录覆盖 Ver9.0、10.0、11.0 三个大版本，这三个版本在启动阶段的表现是有差异的，这也是很多人照着老教程做却在某个版本上失败的原因。

核心思路是一致的：让系统不要正常启动到多用户状态，而是停在单用户（single）模式下。单用户模式不启动完整的服务栈，也不需要输入任何账号密码，直接给一个 root shell。密码恢复的全部前提就建立在这一点上。

差异在于进入的时机和界面。较老的版本启动过程中留给你的中断窗口比较短，需要盯着屏幕、在引导菜单出现的瞬间按键中断；较新的版本引导菜单停留时间稍长，也更容易辨认。不管哪个版本，判断标准是一样的：屏幕上出现引导项列表，能编辑内核启动参数，就说明你抓到了窗口；如果一路滚到系统服务启动日志，那就是错过了，只能重启再来一次。

这里有个心态问题。第一次做的人往往不敢按，怕按坏了设备。实际上在引导阶段按键中断、修改启动参数，是官方文档里就有的标准恢复路径，不是野路子。真正要谨慎的是修改参数时别动其他内容，只追加单个用户模式的标记，改完确认一遍再继续引导。

注意：这一步的操作对象是设备的启动引导程序，不是在系统里敲命令。按错键最多是重新启动一次，但如果手抖改了别的启动参数，设备可能起不来，那就从「找回密码」变成「恢复系统」了，性质完全不一样。

三个版本我都验过，流程骨架没变，变的只是界面和按键时机。所以下面的复现步骤按「通用骨架 + 版本差异提示」来写，你在哪个版本上做，对着看就行。

3. 完整复现：从接管启动到新密码生效的四段命令

前面三个前提过了，这里的每一步才有意义。整个流程可以拆成四段：接管启动、进单用户、改密码、保存并重启。每一段都有它必须完成的目标，缺一段就会出现「看着做完了其实没生效」的情况。

3.1 接管启动过程：GRUB 中断与 single 参数

设备重启的方式有两种：能登录的话直接在命令行里重启，登不进去就在物理设备上断电重启或者按电源键。既然已经忘记密码了，走物理重启这条路。

重启之后眼睛不要离开终端。引导菜单出现的瞬间按键中断，进入编辑模式，找到当前要引导的那一项，编辑它的内核启动参数，在参数行末尾追加单用户模式的标记。

# 在引导菜单里选中默认启动项后按编辑键，找到以 linux 或 kernel 开头的那一行 # 在行尾追加下面这个标记，注意前面留一个空格，不要覆盖原有参数 single # 部分版本习惯用数字形式，作用等价，二选一即可 1

这段操作的关键在于「只追加、不删除」。原有参数决定了内核能不能正确挂载根文件系统，删掉任何一个都可能导致启动卡住。追加完回车确认，然后让系统继续引导。

引导过程会滚过一批日志，最后停在一个不带登录提示的 shell 提示符上，通常就是#或者sh-xx#之类。看到这个提示符，说明单用户模式进成功了，你现在拥有的是不受密码保护的 root 权限。

如果滚完日志最后出现的是正常的login as:提示，说明单用户模式没进成，参数没加上或者加错了位置，重启重来。这一步失败率最高，但也是最没有副作用的失败，重来就行。

3.2 改密的两条路径：passwd 与 tmsh 各管一段

进了单用户模式，摆在你面前有两条路：用系统自带的passwd改，或者用 TMOS 的管理命令行tmsh改。原始记录走的是后者，两条路都能通，区别在于改完之后配置的落盘方式不一样。

先说一个必做的准备动作。单用户模式下根文件系统通常是只读挂载的，直接改密码会失败或者改了不落盘，所以第一件事是重新挂成可读写。

# 单用户模式默认根分区是只读的，不重挂的话后续写操作会失败或丢失 mount -o remount,rw / # 确认挂载状态，输出里能看到 rw 就说明成功了 mount | grep ' / '

然后是改密码。原始记录里的命令在抄录时被吞掉了空格，写成tshmdify auth password root这种样子，直接复制粘贴肯定报错。正确的完整形式是tmsh modify，中间必须有空格。

# 修改 root 底层系统账号密码，命令执行后会交互式提示输入两遍新密码 /usr/bin/tmsh modify auth password root # 修改 admin 管理账号密码，prompt-for-password 表示交互式输入而不是把密码写在命令行里 /usr/bin/tmsh modify auth user admin prompt-for-password # 部分版本也支持这种形式，效果等价，会同样提示输入新密码 /usr/bin/tmsh modify auth password admin

参数逐个说一下。modify表示修改已有对象的属性，不是新建；auth是认证配置这一层；password后面跟的是要改密码的账号名；user admin prompt-for-password这种写法明确指定了交互式提示，好处是密码不会留在命令历史里，也不怕旁边有人瞄屏幕。

在单用户模式下，tmsh建议写全路径/usr/bin/tmsh。原因是单用户模式没有加载完整的环境变量，直接敲tmsh有可能提示 command not found，这不是命令不存在，是 PATH 没配好。这个细节原始记录里没写，但现场踩过的人都知道。

如果你更习惯系统原生命令，也可以直接passwd admin、passwd root。这条路的问题是它只改系统账号，不一定会同步到 TMOS 的认证配置里，改完可能出现「shell 能进但 web 进不去」的割裂状态。所以我一般还是走tmsh，一次改到位。

3.3 保存与重启：save 写在哪一层决定它生不生效

改完密码这一步，很多人就直接重启了，然后发现密码还是老的，于是判定「方法失效」。真正的原因是没有保存配置，内存里的改动重启就丢了。

保存命令的写法取决于你当前在哪个上下文里。原始记录给了两种：save /sys config和save sys config，看着像笔误，实际上是不同上下文下的写法差异。

# 如果你当前在 tmsh 的交互提示符下（提示符形如 (tmos)#），直接这样写 save sys config # 如果你在普通 shell 里，需要用 tmsh 前缀把命令送进管理平面 tmsh save sys config # 带斜杠的写法在某些版本上等价，作为兜底 tmsh save /sys config

保存成功的标志是屏幕上出现类似配置已保存的确认输出，而不是静默返回。如果敲完没有任何反馈、直接回到提示符，要看清楚是不是报错了被滚动刷掉了。

保存之后退出并重启：

# 从 tmsh 交互模式退回 shell quit # 重启设备，让新的认证配置在完整启动流程中加载 reboot

重启过程中设备会走完整的启动流程，服务逐个拉起，这个过程比单用户模式慢得多，耐心等。等到出现正常的login as:提示，用新设的 admin 密码尝试登录 web 管理界面，能进就说明整个流程闭环了。

4. 避坑与排查：五条现场踩出来的记录

流程写出来只有几百字，但现场真正消耗时间的是各种「明明照做了却不动」的情况。下面这五条，每一条都能单独耗掉半小时以上。

4.1 连不上、乱码、敲键盘没反应

现象一：终端连上以后满屏乱码，偶尔能看到几个像字的字符。原因基本是波特率或者数据位对不上。19200 是这套设备的默认值，但如果你之前用这个终端软件连过别的网络设备，它很可能还停在 9600 上。另外数据位被改成 7、校验位被设成 Even，也会造成类似效果。 解决方法是把五个串口参数逐项对照检查，重点看波特率。改完断开重连，不要指望改完参数当前会话自动恢复，串口参数在会话建立时就固定了。

现象二：能看到完整输出，但敲键盘完全没反应，屏幕上不出字。这是流控在作怪。流控开着的时候，终端在等设备的硬件握手信号，设备没发，终端就不发数据，表现出来就是「只读模式」。把 RTS/CTS 和 XON/XOFF 全部关掉，重新连接，键盘立刻恢复正常。

这条还有个变种：多个终端窗口同时连同一个串口。串口是独占资源，第一个连上的占着，第二个连上可能也能显示但无法输入。遇到「昨天还好好的今天不行了」，先看看是不是有别的会话没关。

4.2 命令敲了但提示不存在或没生效

现象三：按照教程敲tshark，提示 command not found。原始记录里有一处把tmsh错写成了tshark，后面跟着一串mdify、tshmdify之类被吞掉空格的残句。真实命令是tmsh modify，tshark是另一个完全不相干的抓包工具，设备上大概率根本没装。 解决方法是别直接复制粘贴原始记录里的命令，手工敲一遍并确认tmsh和modify之间有空格。这个坑最阴的地方在于：它看起来像「方法不适用你当前版本」，实际只是抄错了字符。

现象四：命令敲了，没报错，但登录时密码还是不对。先确认你改的是哪个账号。改 root 不会影响 web 登录，改 admin 才是大多数人要的那一个。再确认命令有没有真的执行完成，交互式提示输了两遍密码之后应该有成功返回，如果中途 Ctrl+C 中断了，等于没改。 还有一个隐蔽原因：单用户模式下没执行mount -o remount,rw /，写操作失败但没抛明显错误。重新挂载再改一遍即可。

4.3 重启之后密码又变回去了

现象五：改完密码当场测试能登录，重启之后又回到旧密码。典型的是漏了保存这一步。改密码只改了运行时的认证数据，没有写进启动配置，重启自然回滚。也可能保存命令用错了上下文，在 shell 里直接敲save sys config而没有tmsh前缀，命令被 shell 当成未知程序丢掉了。 解决方法是改完立即保存，并且确认保存有明确的成功输出，再重启验证。重启后第一件事就是用新密码登录一次，别等别人来报问题才发现没生效。

5. 密码改回来之后：三条我每次必跑的确认命令

密码恢复最容易产生一种错觉：能登录了就等于完事了。实际上密码只是入口，配置有没有被破坏、账号策略有没有被触发、变更有没有留痕，才是决定这次操作算不算收尾干净的东西。所以我在设备重启回来之后，固定会跑三条确认。

第一条，验证两个账号都能进，而不是只测一个。

第二条，确认配置真的落盘了。做法很简单：登录进去之后，主动执行一次读取配置的命令，看输出里是不是新的认证状态；或者直接再重启一次，验证密码依然有效。第二次重启是最笨但最可靠的验证，我一般会挑不影响业务的窗口做这一步，把后悔药提前吃掉。

第三条，把这次变更记下来。恢复密码这件事，做完之后设备看起来和之前一模一样，唯一能证明发生过什么的就是记录。我会记清楚：操作时间、设备标识、进入单用户模式的方式、改了哪几个账号、保存用的哪条命令、重启后验证结果。这些信息在下一次有人问「这密码是谁改的」时，就是唯一的黑匣子。

回过头看，这套流程真正的门槛不在那几条命令上——命令拢共不超过十条，背都能背下来。门槛在于：你知不知道串口那五个参数缺一不可、知不知道 root 和 admin 是两套账、知不知道改完必须保存、知不知道原始记录里那些被吞掉空格的命令不能直接复制。这些都不是「教程」会写的东西，是踩过才长记性的东西。

从那以后我每次做密码恢复，不管多急，都会强制自己先跑一遍「连上设备敲两下回车」这个小动作——链路不通，后面所有的操作都是自欺欺人。这份按版本和阶段拆开的操作清单我整理在文档里，字段和命令都对照着原始记录校对过，需要照着敲的可以直接取来用。

希望帮到你。

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