简介：面向运维工程师与网络技术学习者的F5 BIG-IP密码恢复文档，聚焦管理员密码遗忘后的应急处理场景，适用Ver9.0、10.0、11.0等旧版设备。文档围绕控制台接入环境、登录认证失败后的处理思路、root与admin账户密码修改、配置保存及重启生效等环节展开，并附F5官方解决方案链接与版本测试说明；同时给出超级终端、SecureCRT、PuTTY及19200波特率等连接参数参考，便于读者核对流程、排查误操作风险。资源包共1个docx文件，约92KB，篇幅紧凑，适合作为ADC设备维护时的速查与对照材料。已有537人学习，说明该主题在F5运维实践中具有一定参考需求。对于需要梳理旧版BIG-IP密码恢复方法、整理应急笔记或结合官方文档验证流程的技术人员，这份文档能提供清晰的框架与参考资料入口。

1. 控制台只剩一个 login 提示符：F5 密码忘记后最先撞上的三个死循环

F5 密码重置这件事，平时没人想起来，一旦想起来就是设备已经进不去了。管理页面打不开、SSH 拒绝登录、串口接上去只吐出一个冷冰冰的login:，三个入口同时失效，人是会慌的。我见过最典型的翻车现场：值班的人抱着笔记本蹲在机柜前，SecureCRT 里一片乱码，换成 Putty 还是乱码，最后怀疑设备坏了，其实只是波特率没设成 19200。F5 BIG-IP 的 console 是 19200 波特率、8 数据位、无校验、1 停止位、无流控，这组参数记不住，后面所有步骤都无从谈起。

比乱码更磨人的是第二个死循环：终于看到login:了，root 试一遍、admin 试一遍，全是Login incorrect，而且连续错几次之后连提示都开始变慢——那是账户锁定策略在起作用。第三个死循环藏在文档里，网上流传的 F5 密码破解笔记东拼西凑，把tshark、tclsh这种八竿子打不着的命令混进流程，照着敲当然没反应。这篇笔记就按这三个死循环的顺序往下拆：先把线连通，再把认证链搞明白，最后才动手改密码，中间那些坑我一个个标出来。

2. 串口连不上：19200 波特率下的乱码、无回显与连接超时

先把最容易误判成“设备故障”的一层剥掉。F5 BIG-IP 的控制台口是标准 RS-232 电平的异步串口，出厂参数固定，不跟管理口共用配置。你看到的乱码、敲键盘没反应、光标不动，九成以上是终端软件这一侧的参数和线序对不上，而不是设备 auth 出了问题。这一层没通，后面讨论 root 还是 admin 全是空谈。

2.1 用三个参数把物理链路钉死

我一般不在图形界面里瞎点，先拿命令行把串口参数一次性写死，再用最简单的终端工具验证链路。Linux 下stty是最直接的，它改的是 tty 驱动层的设置，改完再用cat或screen打开，能立刻判断是不是参数问题。

# 确认 USB 转串口设备被识别，通常是 ttyUSB0 / ttyUSB1 ls -l /dev/ttyUSB* # 把串口参数钉死：19200 波特率、8 数据位、无校验、1 停止位 # -crtscts 关闭硬件流控，clocal 忽略调制解调器控制线 stty -F /dev/ttyUSB0 19200 cs8 -cstopb -parenb -crtscts clocal raw -echo # 用最笨的方式验证：直接读串口，按几下回车看有没有 login 提示 cat /dev/ttyUSB0

19200是 F5 全系默认的控制台速率，9.0、10.0、11.0 都一样，别去试 9600 或 115200，试了也是白试。cs8 -cstopb -parenb合起来就是 8-N-1，少一个参数就可能出现“能连上但字符是花屏”的情况。-crtscts和clocal是重点，很多乱码不是因为速率错，而是因为硬件流控被打开了，驱动在等一条永远不来的 CTS 信号，表现就是连接建立、但一个字符都收不到。raw -echo关掉本地回显和行缓冲，否则你敲的字符会被本地终端吃掉一半，看起来像是设备没响应。

如果cat出来还是乱码，先换一根线再换一台机器，别急着怀疑设备。USB 转串口芯片的兼容性在这个场景里是真的玄学，同一根线在 A 机器上好好的，插到 B 机器上就开始丢字符。

2.2 终端软件里的流控与换行符，最容易背锅的两项

图形终端软件的问题更隐蔽，因为界面上那些勾选项默认值各不相同。SecureCRT、Putty、Xshell 连接串口时，有三个地方必须手动确认：速率、流控、以及回车键发出去的是 CR 还是 CRLF。

Putty 的串口配置藏在Connection → Serial里：Connection type选Serial，Serial line填COM3这类端口名，Speed填19200。然后回到Session保存成一个会话，下次直接点。Putty 默认流控是 XON/XOFF，这个默认值对 F5 是致命的——设备端不发 XON，Putty 就一直处于“暂停发送”状态，表现就是连上了、屏幕空白、敲什么都没反应，很多人到这一步就断定串口坏了。

# Linux 下用 minicom 时，同样先关掉流控再进界面 minicom -D /dev/ttyUSB0 -b 19200 # 进入后按 Ctrl+A 再按 O，Hardware Flow Control / Software Flow Control 全部设为 No

minicom 的-b 19200只设了速率，流控还得进配置菜单手动关，这一点很容易漏。关掉之后按Ctrl+A再按X退出，配置会写进~/.minirc.dfl，下次就不用再设了。另外screen /dev/ttyUSB0 19200也是个轻量选择，它默认不做流控协商，反而省事，缺点是退出方式反人类，Ctrl+A再按K才能杀掉会话。

换行符这块，F5 的 console 认 CR，不认 CRLF。Putty 里Terminal → Keyboard有个The Enter key sends选项，默认是CR，如果被人改成CR LF，你按回车以后设备收到的是一串多余字符，登录提示会重新刷一遍，看起来像是“密码输错了自动跳回登录页”。这个坑我在一次换电脑之后踩过，折腾了四十分钟才发现是软件默认配置不一样。

2.3 认准 console 口和线序：RJ45 直通线不是网线接法

物理层最后一个坑是线。F5 设备的 console 口是 RJ45 封装，但走的是串口电平，随机附带的是一根浅色扁平线加 DB9 转接头。那根线的线序是翻转线（rollover），一头 1 脚对另一头 8 脚，和普通网线完全不是一回事。手边没有原装线、随手抓一根网线顶上去，结果就是完全没信号，或者只有零星乱码。

还有一个常见误判：把 management 口当成了 console 口。管理口是 RJ45 以太网，接上去链路灯会亮，ping也可能通，但它跑的是 IP，不给你 shell。真正的 console 口在机箱面板上通常单独标注，位置往往挨着 USB 口，插上去之后设备侧不会有任何指示灯变化，这才是正常的。

串口服务器（terminal server）场景再多说一句：如果用机房里的串口汇聚设备接入，那台设备自己也有速率和流控配置，两头都要设成 19200 8-N-1 无流控，一头改了另一头没改，症状和线序错一模一样。我一般的排查顺序是：先用一根短线直连笔记本，确认设备本身没问题，再去动汇聚设备，避免两个变量一起改，最后不知道是谁的问题。

3. Login incorrect 的背后：F5 的认证链与你敲的命令到底改了谁

链路通了，login:提示稳定出现，接下来才是真正的密码问题。这里最常见的误解是：以为 F5 只有一个管理员密码。实际上 BIG-IP 上面至少有两套彼此独立的身份：Linux 系统层的root，和配置管理层（tmsh / Web 控制台）的admin。搞不清这两者，就会出现“密码明明改了却还是登不上”的怪事。

3.1 root 和 admin 是两套密码，两条路径

root是底层操作系统的超级用户，密码存在系统的 shadow 文件里，管的是 shell、文件系统、进程这一层。admin是 BIG-IP 自己的管理账户，它的密码和权限体系由 tmsh 管理，存在配置里，Web 控制台和 SSH 的管理登录走的都是这一套。

这带来一个很实用的推论：如果你只是忘了admin的密码，而root还能登，那根本不需要进单用户模式，用 root 登录 console 进 tmsh 改一下就行，全程不用重启，业务零中断。反过来，如果两个都忘了，或者root密码从来没设置过、出厂随机化之后没人记录，那就只能走单用户模式这条路——因为改admin密码需要 tmsh，而进 tmsh 需要 root 权限，链条的起点断在 root 上。

很多整理稿把这两件事混成一段，上来就让你敲modify auth password root，问题是这条命令本身就需要你已经在一个有权限的 shell 里。在login:提示符下面敲它，系统只会把它当成一个用户名，然后回你一句Login incorrect。这就是第二个死循环的根源。

3.2 tmsh 为什么在登录提示符下敲不出来

tmsh是 BIG-IP 的配置 shell，它是一个跑在 Linux 上的程序，必须先进系统 shell 才能调用。正常的路径是：console 上用 root 登录 → 得到一个[root@bigip1:Active:Standalone] config #之类的提示符 → 敲tmsh进入配置模式 → 在(tmos)#提示符下执行modify auth ...。

# 前提：已经用 root 身份登录 console，看到系统 shell 提示符 tmsh # 进入后提示符变成 (tmos)#，此时才能执行配置类命令 (tmos)# modify auth password admin # 按提示输入新密码并确认 (tmos)# save sys config (tmos)# quit

tmsh这行单独敲下去，作用是切换上下文，不修改任何东西。modify auth password admin才是真正的改密动作，它会交互式要求输入两遍新密码。save sys config把内存里的改动落到配置文件，这一步不做，重启之后密码会回到旧值——这是踩坑率最高的地方，后面单独说。

同理，网上那些让你在登录失败后“不要关闭连接，直接输入tshark抓包”的说法，是把另一个场景（抓包分析）的步骤错贴进来了。tshark是抓包工具，和密码恢复没有任何关系；tclsh是 Tcl 解释器，也在系统 shell 里才能调用，登录提示符下同样不可用。看到这类步骤，直接跳过。

3.3 账户锁定与审计日志：先看 /var/log/secure 再动手

在动手重置之前，有一个五分钟就能做完的确认动作，能帮你排除掉一半的“假密码错误”：看日志。

BIG-IP 的认证失败记录在/var/log/secure，配置层的登录记录还会进/var/log/ltm。用 root 登录（如果还能登）执行：

# 看最近的认证失败，确认是密码错还是账户被锁 tail -n 50 /var/log/secure # 关注这几类关键字：authentication failure、account locked、Failed password grep -iE "fail|lock|invalid" /var/log/secure | tail -n 30

如果日志里反复出现authentication failure但没有任何成功记录，那确实是密码不对。如果出现的是账户锁定相关的记录，那就是 BIG-IP 的登录失败锁定策略生效了——连续失败若干次之后账户会被临时或永久锁定，此时即使密码输对也登不进去，症状和密码错完全一样。这种情况在 11.x 上比 9.x、10.x 更常见，因为默认策略更严。解锁同样需要 root 权限，从 tmsh 里把锁定状态清掉再试，比盲目重置密码稳得多。

日志还有一个用处：确认你到底在跟哪台设备打交道。生产环境里主备两台机器的密码可能不同步，配置同步不会同步 root 密码，运维交接时只记了备机密码的情况很常见。先确认主机名和 Active/Standby 状态，再决定改哪一台。

4. 进单用户模式重置密码：9.0/10.0/11.0 的完整操作链

root 密码也进不去的时候，就只剩下一条路：让系统在不启动认证服务的情况下起来，直接改 shadow。这就是单用户模式。它不需要任何现有密码，代价是必须重启设备，业务会中断——所以动手之前先确认这台设备是不是承载着不能停的业务，能切走就先切走。

4.1 引导菜单停住与内核参数

操作从 console 上开始，因为整个过程都在引导阶段完成，网络还没起来。先reboot，然后在 GRUB 菜单出现的那一两秒里把引导停住。9.0 和 10.0 用的是老版 GRUB，11.x 的菜单样式略有不同，但套路一致：出现菜单后按方向键或提示的按键停下，选中默认启动项，按e进入编辑。

编辑界面里会看到一行以kernel开头的配置，末尾是root=/dev/sda2之类的根分区参数。把光标移到这一行末尾，空一格，加上single（或者干脆加1），然后按回车返回菜单，再按b引导。

# 编辑内核行示意，重点是末尾追加的 single kernel /boot/vmlinuz ro root=/dev/sda2 ... single

single告诉内核只启动到单用户运行级别，此时不加载网络服务、不启动 tmsh 的守护进程，直接给你一个 root shell，而且不要求密码。这是整个流程能成立的关键，也是它为什么必须物理接触设备——远程 SSH 是拿不到引导菜单的。

引导过程中会刷大量内核日志，滚完之后出现#提示符。这时候文件系统可能是只读挂载的，直接passwd会报Authentication token manipulation error，这是第三个高频坑。先重新挂载根分区为可写：

# 单用户模式下根分区通常是只读的，先改成可写 mount -o remount,rw / # 修改 root 密码，输入两遍 passwd root

mount -o remount,rw /这一步不做，passwd一定失败，报错信息又很含糊，很多人会误以为是权限问题或者文件损坏。改完 root 密码之后，重启进入正常模式，用新密码登录，剩下的工作就回到 tmsh 里做了。

4.2 改 root 密码之后，再用 tmsh 处理 admin

设备正常启动、所有服务起来之后，用新设的 root 密码从 console 登录。这时候不要急着去 Web 界面试 admin，先把 admin 密码也一起处理掉，避免两套密码状态不一致。

进 tmsh 之后有两条路径可以改 admin 密码，官方文档里两个写法都出现过，区别在于交互方式：

# 进入配置 shell tmsh # 写法一：直接改密码，按提示输入新密码两次 (tmos)# modify auth password admin # 写法二：用户级的交互式改密，明确指定用户对象 (tmos)# modify auth user admin prompt-for-password # 改完之后立刻落盘，别等 (tmos)# save sys config # 退出配置 shell (tmos)# quit

第一种写法操作的对象是密码本身，命令会连续要求输入新密码和确认。第二种写法走的是用户对象，语义上更明确，prompt-for-password这个参数就是“交互式询问新密码”的意思，适合在脚本里做半自动流程时使用。两条命令在 9.0、10.0、11.0 上都能用，我一般用第二种，因为它对用户名是显式声明的，不容易在多用户环境下改错对象。modify auth password root这条在原文里也提到过，它的作用是同步系统层 root 密码的校验信息，在已经进过单用户模式改过passwd的情况下通常可以跳过，但如果两套密码体系出现不一致，补一条能让状态对齐。

4.3 保存与重启：save /sys config与save sys config的版本差异

保存这一步值得单独拎出来说，因为它是“改完密码重启就失效”这个经典问题的唯一原因。

老版本 tmsh 的分层语法用斜杠表示路径，写作save /sys config；新版本改成空格分隔，写作save sys config。9.0 和 10.0 上更常见的是前者，11.x 上后者是标准写法。原文里两个都列了，说明作者在三个版本上都试过——这也是判断一份资料靠不靠谱的小技巧，只写一种写法的，多半只在一台设备上跑通过。

表里这四列就是完整闭环。少任何一步，结果都是“当场生效、重启回滚”。特别是save这一步，tmsh 里执行完modify之后提示符会正常返回，没有任何“未保存”的警告，很容易让人以为已经完事了。我现在的习惯是改完密码先不重启，直接tmsh list auth user看一眼对象状态，确认写进内存了，再执行 save，最后才 reboot。

reboot放在最后是有讲究的。保存之后配置已经落盘，重启只是让服务用新凭据重新初始化，验证一遍持久化是否真的生效。如果重启后密码又不对了，说明 save 没执行成功或者执行在了错误的上下文里，这时候还有机会从 console 再进一次单用户模式补救，而不是等到几天后设备真需要重启时才发现问题。

5. 避坑清单：五条最常见的翻车记录

这套流程我自己走过不止一次，也帮别人收拾过残局。下面这几条是重复率最高的，每条都按“看到什么现象 → 为什么会这样 → 怎么处理”来说，对号入座基本能省半天时间。

5.1 重启后密码变回旧的：改动没落到 /config

现象很干脆：当场改完能用，重启之后又是Login incorrect，用户会怀疑自己是不是记错了新密码。

原因是 tmsh 的modify只改运行时配置，BIG-IP 的持久化配置都在/config目录下，没有 save 就没有落盘。更隐蔽的一种情况是 save 执行了但报错，比如磁盘空间满或者配置校验不通过，命令输出被后面刷屏的日志冲掉，人根本没看见。

解决办法是养成分步确认的习惯：先modify，再单独一条save sys config，看到明确的保存成功输出，然后tmsh list auth user核对，最后才reboot。如果怀疑保存失败，直接去/config/bigip.conf里确认时间戳有没有更新，比猜可靠。

5.2 照着敲tshark、tclsh没反应：这些步骤是别的场景混进来的

现象是登录失败后按资料提示输入tshark，屏幕上要么是command not found，要么什么都不发生，然后就没有下一步了。

原因是这些命令属于系统 shell 里的工具，tshark是抓包、tclsh是脚本解释器，和密码恢复没有因果关系。它们被混进流程，多半是早期整理资料时把不同文档的片段拼在了一起，又没在真机上验证。

解决办法很简单：看到流程里出现和“改密码”没有直接关系的命令，先跳过，只保留从登录、进 shell、改密、保存、重启这条主线。判断标准就是这条命令执不执行，对最终能不能登录有什么影响，说不出影响的就不是必要步骤。

5.3 密码明明对了还是登不上：锁定、字符集与键盘布局

现象是确认过密码没打错，但依然被拒，或者输到一半字符就乱了。

原因有三个层面。第一是前面说的账户锁定，连续失败触发的锁定状态不会因为你密码对了就解除。第二是键盘布局，console 下默认是 US 布局，密码里带@、#、!这类符号时，某些终端软件会按本地布局发送，设备收到的字符和你以为的不是一回事。第三是特殊字符在串口传输中被吞掉，尤其是流控没关干净的时候。

解决办法：先用纯字母数字的临时密码验证流程是否走通，确认没问题再改成复杂密码；遇到锁定就查/var/log/secure，从 tmsh 里清掉锁定状态；验证阶段尽量不要用带符号的密码，减少变量。

5.4 单用户模式里passwd报错：根分区还是只读

现象是passwd root返回Authentication token manipulation error或者直接提示无法写入。

原因是单用户模式启动时根文件系统以只读方式挂载，/etc/shadow写不进去。这个报错文案完全不提文件系统，误导性很强。

解决办法是先mount -o remount,rw /再改密码，改完可以mount -o remount,ro /改回去再重启，虽然不是必须，但能避免意外写入。这条顺序不能颠倒，颠倒了一定失败。

5.5 主备两台都改了，同步之后又不对了

现象是主机上改完密码好好的，做了一次配置同步，备机或者主机的登录又出问题。

原因是配置同步只同步 BIG-IP 的配置对象，不同步底层 Linux 的 root 密码，也不保证两台的密码策略一致。如果两台设备的密码策略不同，同步过去的账户对象可能被对方的策略重新校验。

解决办法是两台设备分别确认，主机改完、同步、再登录备机验证一遍。密码策略相关的东西不要指望同步，宁可多登一次。生产环境里更稳的做法是先把密码记进受控的凭据管理系统，而不是靠人脑记。

6. 快速定位：把“密码不对”拆成五层，一层一层往下删

排障最怕的是从头试到尾，试到哪一步碰巧好了就收工，下次还得重来。我更愿意把“登不上 F5”这件事拆成五层，每层有一个明确的判定动作，用最短的路径定位到底卡在哪。

这张表的价值在于顺序。先验物理层，是因为它成本最低、误判率最高；再验认证层，是为了区分“密码错”和“账户锁”，这两种情况处理方式完全不同；权限层用来确认你到底站在哪个上下文里，很多人卡在这里却以为是密码问题；持久化层很多人直接跳过，结果几天后设备重启才发现白干；验证层是唯一的终局判断，没重启验证过就不算解决。

几个能加速定位的小命令，我通常会在动手前先跑一遍：

# 确认设备身份和主备状态，避免改错机器 tmsh show sys hardware | grep -i platform tmsh show cm failover status # 确认当前登录的用户和权限上下文 id whoami # 看认证相关的最近日志，判断是密码错还是锁定 tail -n 30 /var/log/secure

第一组命令解决“我在改哪台机器”的问题，主备环境里这个确认能避免很多事故。第二组解决“我现在是什么身份”的问题，id输出里没有 uid=0 就说明你不在 root 上下文，此时执行任何modify都不会生效。第三组是黑匣子，日志不会骗人，它会直接告诉你失败发生在认证环节还是别的环节。

还有一个细节值得养成习惯：任何改动之前先导一份配置备份。tmsh save sys ucs /var/tmp/before-reset.ucs这条命令会把当前配置打成一个归档文件，出问题能整体回滚。密码重置本身风险不大，但人在 console 前面容易顺手多敲几条命令，有后悔药总比没有强。

血泪经验是这么来的：早些年我在一台设备上改完密码，看到提示符正常返回就以为结束了，没 save 直接 reboot 验证，结果重启后密码回滚，又得重新进一次单用户模式。从那以后我每次动认证配置，都强制走一遍“改 → 单独 save → 查时间戳 → reboot 验证”这四步，一步都不省，哪怕当时觉得多余。密码这东西，验证过的才叫改好了，没验证过的都只能叫“看起来改好了”。希望帮到你。

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