企业官网建设流程全解析

简介：这份文档聚焦 F5 BIG-IP 设备的密码恢复与管理员口令重置，面向需要维护 ADC 设备、又遇到控制台登录受阻的运维人员与网络管理员，内容围绕 Ver9.0、10.0、11.0 三个版本展开。压缩包内仅含 1 个 docx 文件，大小约 92KB，篇幅集中，便于随查随用。文档梳理了通过控制台连接设备后的处理思路，并给出 root 与 admin 账户改密、配置保存及重启生效等关键命令示例，同时附带 F5 官方解决方案链接，方便核对版本差异与操作依据。内容由分享者于 2014 年测试整理，已有 537 人学习，适合作为旧版本 BIG-IP 设备应急维护时的参考笔记，也可用于理解控制台接入参数与 tmsh 口令管理方式；实际使用前仍应结合最新官方文档确认兼容性与安全要求。

1. 机房里那台没人记得密码的 BIG-IP：这是恢复，不是绕过

F5 BIG-IP 这类 ADC 设备最容易出现的场景是：业务还在正常跑，负载均衡和 VIP 都在工作，但管理员账号随着人员离职一起消失了，没人能改配置、加节点、查连接数。这时候需要的是一套走控制台的密码恢复流程，而不是网上那种“绕过认证”的说法。这份 2014 年流传的 docx 笔记覆盖 9.0、10.0、11.0 三个大版本，核心内容其实只有三条 tmsh 命令加一次重启，但真正的难点全在“怎么拿到一个能敲命令的 shell”上。它适合手里有设备物理接触权、必须当天把管理面救回来的运维；如果你连 Console 口都摸不到，后面的步骤一条也用不上。

2. 控制台这条路：19200 波特率和三种终端工具的实际配置

密码恢复的第一道门槛不在命令，而在“你能不能看到那行 login:”。BIG-IP 的管理面认证没有网络侧旁路，SSH 和 WebUI 进不去就是进不去，唯一稳定入口是设备面板上的 Console 口，或者带外管理设备转出来的串口。原文提到的超级终端、SecureCRT、PuTTY 三种工具，本质是同一个串口会话，差别只在参数填在哪一栏、日志存到哪个文件。

2.1 为什么恢复只能走 Console，不能靠 SSH 绕

BIG-IP 的本地账号存在/config/bigip.conf的auth user段里，sshd 和 httpd 都走这套认证。密码丢了，网络上没有任何“重置邮件”或者“密保问题”可走。实际能用的入口只有三个：另一个还活着的 admin 账号、远程认证服务器（LDAP/RADIUS/TACACS+）里的账号、物理 Console。前两个靠运气，第三个靠流程。所以动手之前先把下面这张表对一遍，缺哪一项都会在中途卡住。

最后一行容易被忽略。做这类恢复，我一般会先把 SecureCRT 的会话日志打开，整段 console 输出落盘，比事后补记录靠谱得多。

2.2 串口参数：19200 之外那几个容易填错的位

19200 是 BIG-IP 的控制台默认速率，原文强调这一点是对的，但只写速率不够。真正会让人卡半小时的是流控和停止位：很多 USB 转串口线默认开了 RTS/CTS，接上去能收到字符但发不出去，表现就是“能看到日志、敲键盘没反应”。

在 Linux 跳线机上，我通常直接用 screen 起会话，参数一次写全：

# 先确认 USB 转串口认到了哪个设备节点 dmesg | grep -i tty # 假设是 /dev/ttyUSB0，按 BIG-IP 默认参数直连 sudo screen /dev/ttyUSB0 19200,cs8,-parenb,-cstopb,-crtscts

cs8是 8 位数据位，-parenb关掉奇偶校验，-cstopb表示 1 位停止位，-crtscts关硬件流控，这四项和 19200 一起才是完整的 8N1 无流控组合。screen 里退出用Ctrl+A再按K，别直接关终端窗口，否则串口设备可能被占着不释放。

Windows 侧三种工具填的东西一样，只是位置不同：

1. PuTTY 选 Session 类型为 Serial，Serial line 填 COM3 这类端口号，Speed 填 19200，Connection 里的 Serial 把 Flow control 设成 None。
2. SecureCRT 新建 Serial 会话，波特率 19200，数据位 8，奇偶校验 None，停止位 1，流控全部取消勾选，同时在 Terminal 里把“Local echo”关掉。
3. 超级终端（老系统上还有）在“还原默认值”之后手动把每秒位数改成 19200，流控选“无”。

提示：如果屏幕能出字符但一个键按下去出现两个相同字符，先查本地回显，再查流控，最后才怀疑线序。这个顺序能省掉大半排查时间。

有些平台或改过配置的设备控制台速率是 9600，接上去如果全是方块和乱码，别急着重启设备，先把终端速率降到 9600 试一次，再试 115200。速率试错比拆机快。

2.3 连上以后看到什么：判断链路是否真的通了

参数对了，按一次回车应该出现干净的login:提示；如果是刚上电，会先刷一屏引导日志，然后停在登录提示。这一步的正确判断标准是“字符干净、按键即时回显”，而不是“能看到东西”。半通不通的状态最坑人：能看到日志说明接收方向没问题，敲键盘没反应说明发送方向被流控或者线序卡住了。

原文里有一句容易被误读的提示：认证失败时不要关闭连接。这句话不是说保持会话能绕过什么，而是因为后面要重启设备、在引导阶段抢那几秒的菜单，一旦断开重连，很可能错过窗口，又得再等一轮重启。物理设备的引导菜单停留时间往往只有三到五秒，通过 KVM 虚拟串口还要再加一层按键延迟。

我一般会在登录提示出现后就做三件事：确认回显正常、打开会话日志、把设备型号和当前版本记下来。版本决定了后面用哪套命令语法，9.x 和 11.x 在这一步的差别比想象中大。

3. 从登录提示进到 tmsh：拿到一个能执行命令的 shell

登录提示挡在前面，是因为 sshd 要认证；但只要在引导阶段把系统拉进单用户或维护 shell，认证这一层就整个不在了，你直接就是 root。原文的步骤顺序在这里写得比较跳，把tclsh和tmsh混在一起讲，实际动手时按下面的顺序走会顺很多。

3.1 引导阶段的那几秒：进单用户 shell 的时机

常见做法是：在 console 里执行重启，然后盯着输出别眨眼。11.x 用的是 GRUB，启动时会有一个几秒的菜单，按方向键能把它停住，选中默认启动项按e编辑内核行，在末尾加一个single或者1，回车启动，系统就会进单用户模式，root 免密。9.x 和 10.x 的引导器长得不一样，有的是在boot:提示符下敲启动参数，有的是菜单里直接给一个维护模式选项，具体以现场屏幕上看到的为准。

这里有两个实操细节值得记一下。第一，别用太快的连按，很多带外管理设备的虚拟串口会丢键，宁可按一下停半秒。第二，如果菜单怎么都停不住，可以先看看设备是不是配了自动引导，有些环境把等待时间改成了 0，那就只能在开机瞬间按住某个键，或者改用带外设备的中断功能。

进到单用户 shell 之后，第一件事是确认配置文件所在的文件系统是只读还是读写。单用户模式下/config经常挂成只读，这时候后面的保存命令一定失败，而且报错信息很含糊，容易被误判成命令写错了。

3.2 tmsh 和 tclsh 不是一回事：命令该在哪一层敲

这三层的关系必须分清：最底下是 Linux 的 root shell，tmsh 是跑在它上面的配置 shell，tclsh 是 TCL 解释器，主要给 iControl 脚本用。原文写的是先进tclsh再敲 tmsh 命令，在多数版本上确实能成，因为 TCL 里可以起子进程，但这不是必须的，也不该是第一步。真正稳妥的顺序是先处理文件系统，再进 tmsh。

# 1. 确认 /config 的挂载状态，只读的话后面 save 一定失败 mount | grep -E "/config|/usr" # 2. 如果是只读，重新挂成读写（单用户模式下的常见动作） mount -o remount,rw /config # 3. 直接进 tmsh，不需要先起 tclsh tmsh

mount | grep这一步是为了看清楚当前挂载选项里有没有ro，有就 remount。tmsh直接敲就行，9.x 上 tmsh 功能还不完整，个别操作要回落到bigpipe，但改密码这类基础操作在三个版本里都能用 tmsh 完成。进到 tmsh 之后提示符会变成(tmos)#，看到这个提示符就说明你在配置层了，后面所有命令都在这里敲。

3.3 三条命令改两个密码：root 和 admin 的区别

很多人在这步翻车，是因为没搞清自己在改哪个账号。root是设备 Linux 层的账号，负责串口和底层 shell；admin是 tmsh 和 WebUI 的管理员账号，业务配置都挂在它名下。两个密码是分开存的，只改一个，重启后该进不去还是进不去。

# 在 tmsh 提示符 (tmos)# 下执行 # 改 root 密码，会交互式提示输入两次新密码 tmsh modify auth password root # 改 admin 密码，新一点的版本推荐用这条，同样是交互式输入 tmsh modify auth user admin prompt-for-password # 老版本或者上面那条不认的时候，回落到这条等价写法 tmsh modify auth password admin # 保存配置，把改动写进 /config/bigip.conf save sys config # 退出 tmsh，回到 root shell quit # 重启，让 sshd 和 httpd 重新加载认证库 reboot

modify auth password <用户名>是老语法，交互式要密码；modify auth user <用户名> prompt-for-password是新语法，做的事情一样，只是走对象路径。保存这一步在 9.x 上更稳的写法是save /sys config，带斜杠是按对象全路径定位，10.x 之后两种写法基本等价。reboot不是可选项，虽然理论上重启服务也能生效，但认证库在多个进程里有缓存，重启一次最干净，也顺便验证了新密码确实能过。

注意：11.x 的部分后期版本对 admin 密码加了复杂度校验，输弱口令会被拒，但提示信息往往只说“操作失败”，不告诉你具体哪条规则没过。遇到这种情况换一个大小写加数字加符号的密码重试，别怀疑命令写错了。

4. 三个版本的差异：9.0/10.0/11.0 上到底改了什么

原文一句“Ver9.0、10.0、11.0 测试都通过”很容易让人以为命令完全一样，实际动手时三个版本的差别主要集中在命令语法、保存方式、密码策略和配置同步这四块。这一章把差异摊开，按版本对号入座能少走很多弯路。

4.1 命令语法与对象路径：save /sys config 和 save sys config

先给一张对照表，能覆盖绝大多数现场情况。表里没写的部分以设备上tmsh help的输出为准，不同补丁级别会有细微出入。

保存这一步值得单独说。带斜杠的save /sys config是按对象路径逐级定位，解析更严格但兼容性更好；不带斜杠的save sys config是简写形式，11.x 上更常见。如果保存报出和“对象找不到”相关的错误，先换成另一种写法试一次，比翻文档快。

4.2 root 密码不进配置同步：单机和双机恢复的两种结局

这是最容易吃哑巴亏的地方。admin 账号存在/config/bigip.conf里，开了配置同步的双机环境，一台改完做完 config sync，另一台会跟着变；但 root 密码存在本机的/etc/shadow，属于系统层，配置同步根本不管它。

结果就是：主设备恢复完了，一切正常，业务切回来；某天主设备维护，流量切到备机，发现备机 root 和 admin 都进不去，只能再走一遍控制台。双机环境我的做法是两台分别插上 console 各做一遍，别指望同步。改完 admin 之后如果要做 config sync，还得确认同步方向，别把备机上原本没问题的配置盖回去。

单机环境相对简单，但有个反直觉的点：改完密码重启后，业务会中断几十秒到几分钟，取决于配置加载速度。有维护窗口就老老实实等窗口，别在业务高峰赌运气。

4.3 改完之后怎么验证：四个必须过的检查点

密码改完、设备重启完，不代表事情结束。我一般按下面四条依次验证，全过才算收工。

# 1. 配置完整性自检，能过说明 /config/bigip.conf 没被写坏 tmsh load sys config verify # 2. 确认版本和当前启动卷，避免在错误的卷上折腾 tmsh show sys version # 3. 看 tmsh 层的账号列表，确认 admin 存在且没被改到别的分区 tmsh list auth user # 4. 翻最近的日志，确认没有认证相关的持续报错 tail -n 50 /var/log/ltm

load sys config verify是只读校验，不会真正加载配置，可以放心跑；list auth user能看到账号挂在哪个 partition、认证来源是 local 还是远程，这一步能提前发现“改了本地 admin，但设备实际走的是 RADIUS”这种尴尬情况。日志那条不是走过场，认证失败会在/var/log/ltm里留痕，连着刷错误说明密码策略或者其他地方还有问题。

5. 排查与避坑：五条让恢复流程翻车的现场记录

这一章是按“现象、原因、解决”整理出来的，全部来自实际操作中踩过的坑。每一条单独看都不复杂，凑在一起就能让一次半小时的恢复拖成半天。

5.1 现象：串口全是乱码，偶尔蹦出几个能认的字

原因基本锁定在速率和流控上，最容易被忽略的是 USB 转串口线的芯片兼容性——有些廉价线在 19200 下会丢位。解决顺序是：先确认终端速率是 19200 而不是 9600，再把流控全部关掉，然后换一根线或者换一台跳线机。如果换了线还是乱码，试试把终端设成 7 数据位，个别老固件的控制台参数被改过。判断是否真的通了，看能不能干净地按回车刷出一行新的提示符，而不是看屏幕上有没有字。

5.2 现象：引导菜单一闪而过，怎么按都停不住

原因有两层。表面上是引导等待时间太短，深层是 KVM 或串口服务器的按键延迟——你以为在按，字符还在路上。解决方式是提前把会话连好，重启命令敲下去之后立刻开始有节奏地按方向键，而不是等看到菜单再反应。带外设备如果有“发送中断”或者“发送 Break”的功能，用它比按键可靠。实在抢不到窗口，检查设备是不是开了自动引导，把等待时间临时调长。

5.3 现象：tmsh 里保存配置报错，或者改完重启密码没生效

最常见的原因是单用户模式下/config还挂在只读，save根本没写进去，命令却返回了一个很含糊的错误。先mount | grep config看一眼，有ro就 remount 再保存。另一个原因是命令敲在了错误的层级，比如在 tclsh 里直接敲 tmsh 语法，命令被当成 TCL 语句解析，报的错和真实原因完全无关。解决办法很简单：退出到 root shell，重新tmsh进配置层再执行。

5.4 现象：改完 admin 密码，重启后 WebUI 还是提示认证失败

这里有两个高频原因。一是只改了 root 没改 admin，或者反过来，两个账号是分开的，必须都覆盖。二是设备的认证来源不是 local，而是指向了远程认证服务器，本地改的密码在认证链路上根本没被使用。用list auth user和list auth确认认证源，如果是远程认证，得先解决远程侧账号，或者临时把认证源切回 local 再改。切认证源属于影响面较大的操作，做之前要有回滚方案。

5.5 现象：照着原文敲 tshark，报命令不存在

原文里那条tshark是个明显的笔误或者张冠李戴。抓包工具在设备上即便存在，对找回密码也毫无帮助——密码既不在网络流量里，也不在抓包里，认证是本地比对哈希。这条命令直接跳过，别在它上面浪费时间。类似的还有原文把tclsh写成必经步骤，实际上 tmsh 在 root shell 里直接可调，多进一层只是多一个出错点。

6. 把一次救火变成标准动作：恢复前后的检查表和留痕

密码恢复这类操作，真正决定效率的不是命令记得多熟，而是有没有一套固定动作。我后来把这套流程固化成了两张表，做之前填一遍，做完再填一遍，中间很少再出岔子。

还有一个习惯是密码落地方式。改完的密码不要只存在某个人脑子里，也不要随手写在便签上贴在机柜门内侧。我的做法是改完立刻写进受控的凭据管理系统，同时在变更单里记录“谁在什么时间、通过 console 重置了哪台设备的哪个账号”，只记账号不记明文。这套记录在半年后换人接手时价值最大，比任何文档都管用。

另外提醒一句版本边界：这三个版本的方法能跑通，不代表更新的固件上还能照抄。厂商在每个大版本都会调整认证相关的东西，密码策略、默认账号状态、引导方式都可能变。真遇到新版本，先看设备自己的tmsh help输出，再看官方知识库对应编号的文档，别拿 2014 年的笔记硬套。

从那以后我每次碰这类恢复，不管多急，都会先把会话日志打开、把两个账号都改一遍、把双机各做一次，宁可多花二十分钟，也不愿意半夜被叫起来重来一遍。希望帮到你。

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