F5 BIG-IP密码恢复：串口控制台与维护模式tmsh改密指南

简介：F5 BIG-IP 设备管理员密码遗忘后的恢复操作文档，面向网络运维工程师、系统管理员及安全测试学习者，聚焦 Ver9.0、10.0、11.0 三个版本的控制台破密与密码重置流程。内容围绕串口终端（超级终端、SecureCRT、PuTTY，波特率 19200）连接设备，通过 tclsh 与 tmsh 命令修改 root、admin 账户密码并保存配置、重启生效，同时附有两篇 F5 官方解决方案链接作为参考，便于读者对照官方文档核验操作边界。整份资源为单个 docx 文件，压缩包约 92KB，体量轻便，适合离线保存或打印成排障手册随时查阅。目前已有 537 人学习下载，可作为运维人员应急恢复设备访问权限时的操作参照。

1. 串口敲了三遍都是 Login incorrect：先别急着重启设备

把 Console 线插上，波特率设成 19200，回车，屏幕上跳出login:，用户名敲 admin，密码连输三遍，全是Login incorrect。设备还在正常跑业务，负载均衡、会话保持都没停，唯独管理面进不去了。这时候最容易犯的错误就是反复硬重启，重启并不能让你登进去，只会多消耗一次业务中断窗口。这类事在机房交接、老管理员离职、密码本丢失、密码强制期到了没人改的场景里出现得非常多，翻车的人往往不是不会配置，而是没走过密码恢复这条路。F5 BIG-IP 的密码恢复有明确前提：你必须能物理接触到设备，或者能连到它的控制台端口。手上有串口线、有super terminal、SecureCRT 或 PuTTY 中的任意一个，再对着版本号选择命令，整件事就能从“设备成砖”变回“二十分钟搞定”。

2. 控制台连不上：19200 波特率、8N1 与串口链路的排查顺序

2.1 三种“连不上”其实根因完全不同

先别急着怀疑设备坏了。控制台连不上的现象大致分三种，每种对应的根因完全不一样。

第一种是窗口打开一片空白，敲回车没有任何回显。根因通常在物理链路：串口线是直通线还是交叉线接错了、USB 转串口驱动没装、COM 口选错了、或者 Console 口被另一个终端会话占着（Windows 下常见于上一次 SecureCRT 窗口没关干净）。第二种是满屏乱码，像一屏雪花点，说明链路是通的、设备也在输出，只是波特率对不上。第三种是能看到启动日志刷过去，但刷完之后没停在你预期的位置，这往往是设备已经启动完并进入了多用户模式，控制台的登录提示被前面滚过去的日志顶掉了，往回翻一屏就能看到login:。

还有一种容易被误判的情况：设备刚上电时串口是没输出的，风扇转起来之后才开始刷 BIOS 和引导信息，这段时间可能是十几秒到几十秒。有人在这段时间里反复插拔线、换终端软件，反而把本来正常的连接搞乱了。

2.2 控制台参数就这一组，照抄即可

BIG-IP 设备的控制台参数在各版本里基本一致，把下面这张表对齐，八成的连不上问题就没了：

流控这一项最容易被忽略。SecureCRT 里默认可能开着 RTS/CTS，PuTTY 里默认是 XON/XOFF，这两种在 Console 口上都不该开。开着流控的典型表现是：能收到设备发出来的日志，但你敲的字符设备收不到，或者敲一个字符回显一串。

2.3 用命令行先把串口链路验通

Windows 上用 SecureCRT 或 PuTTY 图形界面配置没问题，但在 Linux 或 macOS 上排查时，直接用命令行验证串口通不通更快，也更适合写进操作记录：

# 确认 USB 转串口已被内核识别，拿到设备名（一般是 ttyUSB0） dmesg | grep -iE 'ttyUSB|ftdi|pl2303' # 设置串口参数：19200 波特率、8 数据位、1 停止位、无校验、关闭硬件流控 stty -F /dev/ttyUSB0 19200 cs8 -cstopb -parenb -crtscts # 直接读串口输出，看有没有启动日志或登录提示刷出来 cat /dev/ttyUSB0

dmesg那一行是在确认驱动层有没有认到转换芯片，如果这条命令什么都没有，后面所有操作都是白费，先去装驱动。stty那一行是把串口参数一次性设死，cs8是 8 位数据位，-cstopb表示 1 位停止位，-parenb表示无校验，-crtscts关掉硬件流控，这四个参数和控制台要求一一对应。最后的cat是只读模式，能看到日志滚动就说明物理层和波特率都对。

如果你更习惯用现成工具，screen /dev/ttyUSB0 19200一行就能连上，退出用Ctrl+A再按K。macOS 上设备名一般是/dev/tty.usbserial-xxxx，参数一致。

判断链路是否正常的标准很简单：能看到完整的、可读的启动日志，说明链路和波特率都正确；只能看到乱码，说明链路通但波特率错；完全没输出，说明线、驱动或端口有问题。把这三条判断做扎实，再往下走维护模式才有意义。

3. 登录被拒之后：维护模式里 tmsh 改密码的完整顺序

3.1 为什么在登录界面永远改不了密码

根因其实很直白：BIG-IP 的认证走的是本地用户库，正常多用户模式下，任何改密码的操作都要求你先通过认证，包括tmsh modify auth password这类命令本身也要有权限。密码一忘，认证这道门就锁死了，形成死循环——想改密码得先登录，想登录得先有密码。

出路是让设备以单用户或维护模式启动。这个模式下完整的多用户服务不会被拉起来，控制台直接给你一个 root shell 或 tmsh 提示符，不需要经过密码认证。这一步本质上是把权限边界从“账号密码”换成了“物理接触设备”，能摸到串口线的人本来就有这台设备的最高控制权，所以它属于厂商支持范围内的密码恢复流程，不是绕过安全机制。

进入方式随版本有差异：9.x 和 10.x 通常在启动过程中从串口控制台中断引导流程，在启动菜单里选择单用户或维护模式；11.x 的启动选项更简洁，同样是在控制台按提示进入维护模式。具体菜单项以设备实际启动时打印出来的提示为准，不同硬件平台的中断时机不太一样，常见做法是设备一上电就在串口窗口里连续敲方向键或空格，把启动菜单叫出来。

3.2 改 root 和改 admin 是两件事

进到维护模式之后，很多人第一反应是敲passwd，结果发现改了也不生效，因为 BIG-IP 的账户密码存在自己的配置体系里，不是简单一个passwd能覆盖的。正确入口是 tmsh：

# 维护模式启动完成后，控制台通常直接落到 shell 提示符，先进入 tmsh 命令行 tmsh # 修改 root 账户密码，执行后交互式输入两次新密码 modify auth password root # 修改 admin 账户密码；prompt-for-password 会提示输入，避免密码明文进命令历史 modify auth user admin prompt-for-password # 部分版本支持这条写法，同样会交互式提示输入 modify auth password admin

第一条modify auth password root改的是底层 root 账户，它决定了你能不能进 root shell、能不能做后续的系统级操作，很多人在维护模式里能进 tmsh 但重启后进不去 root shell，就是漏了这一步。第二条和第三条改的是 admin 账户，这是 Web 管理界面和日常 tmsh 登录用的账号。

优先用prompt-for-password这个写法，因为交互式输入不会把密码留在 shell history 里，也不会因为终端转义问题把特殊字符吃掉。9.x 和 10.x 上modify auth password admin这种简写支持得更好，11.x 上更推荐modify auth user admin prompt-for-password，两条命令在原文列出的三个版本上都测过，哪条能过就用哪条。

注意：新密码必须满足设备的密码策略，长度不够或者字符种类太少会直接被拒绝，报错一般是提示密码不满足复杂度要求。这时候不要怀疑命令写错了，换一个符合策略的密码再敲一次。

3.3 save 和 reboot 的顺序错了等于白改

这一步是最容易翻车的地方。改完密码不保存就重启，设备从持久化配置里重新加载的仍是旧密码，你会发现自己折腾半小时，重启回来还是Login incorrect。命令顺序必须是这样：

# 11.x 写法：把运行中的配置写入持久化配置文件 save sys config # 9.x / 10.x 写法：路径式，效果相同 save /sys config # 退出 tmsh，回到 shell quit # 重启设备，让多用户模式用新配置重新加载 reboot

save sys config和save /sys config是同一件事的两种写法，11.x 用前者，9.x 和 10.x 用后者，写错了会提示语法错误。这个动作把内存里的运行配置刷进持久化配置文件，不执行它，重启就是一次完整的回滚。

quit只是退出 tmsh，不影响已保存的内容，但建议保留这一步，让 shell 状态干净一些，避免reboot在某些版本上因为 tmsh 上下文没退干净而报错。

reboot是必须的。维护模式下的修改在重启前不会让多用户模式重新加载配置，重启之后设备才会用新密码启动完整的服务。重启前务必确认业务可以中断，双机环境先动备机，这是基本纪律，不是可选项。

3.4 重启后怎么确认真的生效了

重启完成后串口会重新刷一遍日志，等到login:出现，用新密码登录。登进去之后别急着关窗口，先做两个确认：

# 确认 admin 账户仍然存在且处于启用状态 tmsh list auth user admin # root shell 下直接核对本地账户条目是否存在 grep -E '^(root|admin):' /etc/passwd

第一条看的是配置层的账户对象，能列出来说明账户没被禁用、没被误删。第二条在 root shell 下执行，看的是系统层的账户条目，两个都正常，说明密码恢复这件事从头到尾走通了。Web 管理界面也顺手登一次，因为串口能进不代表 HTTPS 管理口能进，中间还可能卡在认证源上，那属于下一章的内容。

4. 密码改完还是登不进：认证源、账户锁定与双机不同步

4.1 本地密码改了但登录仍失败的三条支路

串口能用新密码进，Web 界面还是提示密码错误，这种情况我见过不止一次，根因通常不在密码本身，而在认证路径。第一条支路是设备配置了远程认证源，认证请求被转发到外部的目录服务或者认证服务器，本地 admin 账户只是兜底，甚至被显式禁用。第二条支路是账户被锁定，之前连续输错太多次触发了锁定策略，改密码不会自动解锁。第三条支路是双机环境只改了一台，备机上还是旧密码，主备切换之后就“失灵”了。

先把当前生效的认证配置看清楚：

# 查看当前认证源配置，确认本地认证是否被远程认证源覆盖 tmsh list auth source # 确认账户没有被禁用、没有过期 tmsh list auth user admin # 双机环境：查看配置同步状态 tmsh show cm sync-status

tmsh list auth source列出的是当前认证源，如果里面显示的是远程类型而不是本地，那本地改的密码自然不会生效，得先把认证源切回本地，或者确认远程侧那个账号的状态。部分版本这个对象不在 tmsh 下，那就从 Web 界面的用户管理里去核对认证配置，路径大意是系统设置下的用户与认证相关菜单。

tmsh list auth user admin除了看账户在不在，还要看它的状态字段有没有被标记为锁定或禁用。

tmsh show cm sync-status是双机必看的，它告诉你两台设备的配置是同一条时间线上的，还是已经分叉了。

4.2 双机环境：为什么备机密码没变

配置同步这件事有个前提：改动发生在主用设备上，并且执行了配置同步动作，备机才会拿到新的配置。如果只在主用设备上改完save就结束了，备机的配置文件里仍然是旧密码，一旦发生切换，新管理员就会被挡在门外。

正确做法是改完并保存后，主动触发一次配置同步，再确认同步状态是同步完成的。同步完成之后，别只看主用设备，直接在备机的串口上登一次，用新密码验证。这一步花不了两分钟，但能省掉一次夜里被叫起来处理切换失败的麻烦。

注意：双机环境下的密码恢复，永远先动备机，验证通过再动主机。顺序反了，等于在最不该中断的时候中断业务。

4.3 会过命令但登不上：特殊字符和终端转义

还有一种很隐蔽的情况：tmsh 里执行改密码命令，提示成功，没有报错，但登录就是失败。原因通常出在密码字符在传输过程中被吃掉了。串口终端对某些字符有特殊处理，比如退格、控制字符；从别处复制粘贴密码时，很容易带上不可见字符；终端软件的键盘映射也可能把某个符号转成另一个。

我的做法是分两步走：先用纯字母数字的临时密码改一次，登录验证流程通了，再从 Web 界面或者登录后的 tmsh 里把密码改成符合复杂度要求的那一个。这样能把“命令对不对”和“字符传没传对”两个变量拆开，不然你会在命令语法上白找半天。

5. 避坑记录：五条把设备改成“砖”的常见操作

5.1 照着老文档敲mdify，报语法错误

现象：在 tmsh 里敲mdify auth password root，返回语法错误，提示无法识别这个参数或者命令不存在。

原因：这是一份流传很广的老文档里的拼写错误，modify少写了一个o。这类错误在多次转抄的资料里特别顽固，看起来像命令，实际不是。

解决：认准modify、auth、password三个词，敲完先看一眼再回车。遇到 tmsh 语法错误，先用help或者命令补全确认正确拼写，别怀疑设备有问题。

5.2 串口一片乱码，越换软件越乱

现象：SecureCRT 打开是乱码，换 PuTTY 还是乱码，换超级终端依旧乱码，于是开始怀疑设备系统坏了。

原因：乱码几乎只有一个根因，波特率不对。三款软件默认的波特率可能是 9600 或 115200，不是 19200，换软件不换参数当然还是乱码。

解决：先把波特率改到 19200、8N1、无流控，再做别的判断。判断标准很干脆：乱码说明链路通，参数错；没输出说明链路断。

5.3 改完没 save 就 reboot，重启回来还是旧密码

现象：维护模式里改密码提示成功，重启之后用新密码登录，依旧Login incorrect。

原因：修改只存在内存里，没有写进持久化配置，重启就是从旧配置重新加载。

解决：save sys config或save /sys config必须在reboot之前执行，执行完再quit、再重启。这是血泪经验，不保存的重启等于主动回滚。

5.4 只改了 root，没改 admin，Web 界面进不去

现象：串口用新密码能进 root shell，但 Web 管理界面和日常 tmsh 登录还是失败。

原因：root 和 admin 是两个独立账户，modify auth password root只影响前者。很多人以为改一个就全好了，实际只修了一半。

解决：两个账户都要改，modify auth password root加modify auth user admin prompt-for-password，一条都不能少，改完再统一保存。

5.5 把抓包工具当成改密码的步骤，串口里敲tshark

现象：照着某份资料在串口里敲tshark，屏幕上没反应或者直接报错，后面的步骤全卡住。

原因：tshark是抓包工具的命令行版本，和改密码没有任何关系，这是资料在转抄时把两件事拼到了一起。控制台不是完整 shell，维护模式下可用的命令也有限，敲错一个词就卡在原地。

解决：认准三件事——进 tmsh、modify auth password、save加reboot。任何要求你在串口里跑抓包工具的步骤，都可以直接跳过。

6. 快速定位：从现象到验证命令的一张对照表

真到了现场，时间紧、业务在跑、旁边还有人等着，按现象查表比从头想流程快得多。下面这张表是我自己排故障时用的顺序，从上往下走，基本不会绕路：

配合这张表，再记住三条验证命令，绝大多数情况当场就能定性：tmsh list auth user admin看账户在不在、有没有被锁；tmsh list auth source看认证走的是本地还是远程；grep -E '^(root|admin):' /etc/passwd在 root shell 下确认系统层账户条目还在。

还有一个动作值得养成习惯：每次改完密码，先别关串口窗口，退出去重新登录一次。看起来多余，但这一步能把“保存没生效”和“密码记错了”区分开，等真出问题时你就知道这一分钟有多值钱。

从那以后我每次做密码恢复，都强制自己走一遍固定顺序：先确认串口参数再动手，改完 root 和 admin 两个账户，保存、退出、重启，最后用新密码重新登录验证一遍，双机环境先备机后主机。这套顺序不需要记性，只需要纪律。希望帮到你。

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