企业官网建设流程全解析

简介：面向运维工程师与网络安全管理者的F5 BIG-IP密码恢复专题文档，聚焦管理员密码遗忘后的应急处置与授权维护场景，适合具备一定ADC设备基础、需要快速查阅恢复思路的读者。内容围绕Ver9.0、10.0、11.0三个系统版本展开，涵盖控制台连接条件、终端模拟器参数、TCL与tmsh命令组合、root及admin账户处理、配置保存与重启生效等关键环节，并保留版本适用性说明、测试结论和官方解决方案链接，便于判断方案边界、理解命令用途并减少误操作。资源包共1个docx文件，约92KB，体量轻便，可作为设备维护时的速查手册或实验环境中的对照材料。目前已有537人学习，主题在负载均衡与应用交付运维中具有持续查阅价值。

1. 凌晨两点的反直觉现象：密码输错反而进了 shell

值班同事把 rollover 线插进那台应用交付控制器（ADC）的 console 口，敲了三遍 admin 密码，认证失败。按常理这时候该收到"登录不正确"然后退回登录提示符，结果屏幕停在一个login:之后直接给了个#提示符——他愣了两秒才反应过来自己拿到了 root shell。这个反直觉的现象，就是 BIG-IP 系列设备在 9.x / 10.x / 11.x 上密码恢复流程的起点，也是网上那份流传多年的 docx 文档能成立的根本原因。它解决的不是"入侵别人设备"，而是运维侧最典型的一类事故：设备还在、网络还通、配置还在跑，唯独管理员把密码忘了，Web 配置界面和 SSH 全部进不去。适合的读者很明确——手上有设备物理接触权限、走完了变更流程、需要在一小时内把管理面恢复回来的运维工程师。前提必须说在前面：这套操作要求你对该设备有明确的管理授权，并且能接触到它的 console 口，任何远程直销式的"破解"都不在讨论范围内。

2. 把 console 链路打通：19200 波特率、线序与终端参数

物理链路不通，后面所有命令都是空谈。这一章把"能看见登录提示符"这件事拆到可复现的程度，包括线材、串口参数、终端软件配置和链路自检，因为我在现场见过太多人卡在第一步——线插好了，屏幕一片黑，然后开始怀疑设备坏了。

2.1 先确认入口合法性，再谈技术动作

动手之前先做三件事，顺序不能反。第一，确认这台设备的资产归属和你的操作授权，密码恢复属于管理面变更，正常流程里应该有一张变更单或者至少一封审批邮件，事后审计会查这个。第二，确认你能物理接触到设备，console 口通常在前面板或后面板，RJ45 或 DB9 形态都有，具体位置查对应型号的硬件手册。第三，确认这台设备当前不是单机运行的关键节点，如果是 HA 双机，先确认对端健康、能接管流量，再动这一台。

提示：不要在业务高峰期做密码恢复。虽然这套流程本身不改业务配置，但最后一步需要重启，重启期间这台设备不承载流量，HA 对端会短暂承压。

很多事故不是技术问题，是流程问题。我见过一次，工程师图省事跳过了 HA 健康检查，结果重启的那台正好是对端认为"主"的那台，双机同时抖动，业务侧报了五分钟的 502。技术动作本身没错，错在顺序。

2.2 线序与串口参数：19200-8-N-1 是怎么来的

BIG-IP 系列设备的 console 口默认参数是 19200 波特率、8 数据位、无校验、1 停止位、无流控，这套参数在 9.x 到 11.x 上是一致的。线材方面，RJ45 console 口用的是 rollover 线（一端线序完全反转），不是普通的直通网线，更不是交叉线；DB9 口则用标准的 null-modem 线。用错线最常见的表现就是屏幕全黑或者满屏乱码，很多人第一反应是波特率不对，其实是线序反了。

现在的笔记本基本没有原生串口，USB 转串口芯片是绕不开的一环。FTDI 芯片兼容性最好，CH340 便宜但在部分系统上驱动不稳，PL2303 老芯片在新内核上偶发丢字符。我的习惯是随包带一根 FTDI 的线，出问题少一半。

Linux 下确认设备节点，插上线之后看内核日志：

# 插上 USB 转串口后，确认系统分配的设备节点 dmesg | tail -20 # 常见结果是 /dev/ttyUSB0，部分芯片是 /dev/ttyACM0 ls -l /dev/ttyUSB*

dmesg输出的最后几行会告诉你芯片型号和分配到的 tty 节点。如果什么都没出现，先换 USB 口、换线，别急着怀疑驱动——我遇到过三次"设备没识别"，两次是线坏了，一次是 USB 口供电不足。

2.3 终端软件参数对照：SecureCRT、PuTTY、minicom

三款常用工具的配置项名称不一样，但本质是同一组参数。下表是我自己整理的一张对照，照着填不会错。

流控这一项特别容易漏。RTS/CTS 硬件流控如果开着，某些线材上会导致"能发不能收"，表现是你能看到自己敲的字符但设备回显不来，或者反过来。一律关掉最省事。

Linux 下用screen是最快的：

# 直连 console，参数按 19200-8-N-1 screen /dev/ttyUSB0 19200 # 退出会话：先按 Ctrl+A，再按 K，然后确认 y

screen的第二个参数就是波特率，数据位、校验、停止位默认就是 8N1，不需要额外指定。会话里如果看到登录提示符，链路就通了。退出时注意别直接关终端窗口，用Ctrl+A再K正常退出，否则下一次连接可能报 "device busy"。

2.4 用脚本扫一遍波特率，避免瞎猜

如果你不确定设备当前配的是不是 19200（比如上一任管理员改过），可以用 pyserial 写个小脚本把常见波特率扫一遍，看到哪个能返回可读字符就说明对了。这个思路比一个个手动试快得多。

import serial import time # 常见 console 波特率候选 CANDIDATES = [9600, 19200, 38400, 57600, 115200] PORT = "/dev/ttyUSB0" for baud in CANDIDATES: try: # 8N1，无软硬件流控，超时 1 秒 with serial.Serial( PORT, baud, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, xonxoff=False, rtscts=False, timeout=1, ) as ser: ser.reset_input_buffer() ser.write(b"\r\n") # 敲一个回车，触发提示符 time.sleep(0.5) data = ser.read(256) # 能读出可打印字符，说明波特率大概率对 printable = [b for b in data if 32 <= b < 127] if len(printable) > 5: print(f"[HIT] {baud} -> {data[:80]!r}") else: print(f"[miss] {baud} -> {len(data)} bytes") except serial.SerialException as e: print(f"[err ] {baud} -> {e}") break

脚本逻辑很直白：对每个候选波特率打开串口、发一个回车、读回 256 字节，统计其中可打印 ASCII 字符的数量。波特率不对时读回来的是乱码或者干脆没数据，可打印字符极少；波特率对了会看到登录提示符之类的文本。timeout=1是必须的，不然read会一直阻塞。reset_input_buffer()用来清掉上一次尝试残留的字节，避免误判。

注意：扫描脚本只适合在你已经确定设备型号和版本的前提下做通道确认，不要拿它去扫不明的串口设备。

链路打通的标准是三件事同时成立：屏幕上能看到login:提示符、你敲字符时设备有回显、敲回车能换行。三者缺一，先回去查线序和流控，别往下走。

3. 从认证失败落到 root shell：命令链路与版本分水岭

链路通了之后，真正的动作集中在几十秒内。这一章要把三个问题讲透：为什么密码错了还能拿到 shell、每条命令到底改了什么东西、以及为什么 11.x 之后这套流程开始出现版本边界。

3.1 认证失败落到 shell 的机制

在 9.x / 10.x / 11.x 这三个版本上，console 口的登录处理和 SSH 不一样。console 上的login:走的是本地 PAM 认证，认证失败后并不会把你踢回登录提示符循环，而是降到一个受限的维护 shell。这个设计初衷是给现场工程师留一条恢复通道——设备在机房里，插着 console 线的人必然有物理接触权限，那么给他一个 shell 在安全模型上是可以接受的。代价就是密码在 console 面前失去了最后一道防线，这也解释了为什么所有厂商文档都会强调 console 口要物理上锁。

提示：正因为这个机制存在，机房的物理安全等级和 console 口的访问控制，比密码复杂度重要得多。密码恢复流程做得再顺，也不代表可以放松物理管控。

走下去的前提是你确实看到了#提示符。如果认证失败后仍然停在login:循环，说明当前版本或当前配置不走这条路，直接跳到 3.5 节。

3.2 进入 tmsh 并修改 root 密码

拿到 shell 之后，先确认自己在什么位置。这个 shell 可能已经是 root 权限的 bash，也可能是一个受限环境，id和whoami各敲一次，两秒钟的事，能省掉后面一串权限报错。

# 1) 确认当前身份和权限 id whoami # 2) 进入 tmsh（文本配置 shell，设备的配置命令都在这里） tmsh # 3) 修改 root 密码，按提示输入两遍新密码 modify auth password root # 4) 修改 admin 密码，两种写法等价，任选其一 modify auth user admin prompt-for-password # 或 modify auth password admin # 5) 保存配置，两种路径写法都合法 save sys config # 或 save /sys config

逐条说清楚。tmsh是设备的配置 shell，所有modify、save、show类命令都在它的上下文里执行，不在 bash 里敲。modify auth password root会交互式提示输入新密码并二次确认，输入时屏幕不回显，这是正常的。modify auth user admin prompt-for-password和modify auth password admin效果一致，前者是"对指定用户提示输入新密码"，后者是"改指定账户的密码"，两条都是官方认可的写法，我一般用第一条，语义更直白。

save sys config把当前运行配置写入持久化存储，这是整个流程里最容易漏、后果最严重的一步，第 4 章会单独说。

3.3 退出与重启的顺序不能乱

命令执行完不等于生效。tmsh 里改的是运行配置，必须落盘再重启，重启后从持久化配置加载，新密码才真正固化。顺序是：先quit退出 tmsh 回到 shell，再exit退出 shell，最后reboot。

# 从 tmsh 回到 shell quit # 确认配置已经落盘（可选，看一眼更安心） tmsh show sys config | head # 退出 shell exit # 重启设备，让新密码在启动流程中生效 reboot

reboot之后 console 会滚一大段启动日志，正常情况两三分钟回到login:。这个过程里不要拔线、不要 Ctrl+C，中断启动流程可能把设备留在半启动状态，那时候就真得走恢复镜像了。

3.4 一个容易被忽略的点：root 和 admin 是两个账户

很多人只改了 admin，重启后发现 Web 界面能进，但某些底层维护操作还是被拦——因为 root 没改。反过来也一样。这两个账户的职责不同：admin 面向 Web 配置界面和日常管理，root 面向系统层操作。密码恢复时两个都要处理，别只挑一个。我在现场见过一次，工程师改完 admin 就走了，两周后要做系统级排障，root 密码还是那个谁都不知道的旧值，又得重新插一次 console 线。

3.5 版本分水岭：11.x 之后行为变了

前面这套流程在原文标注的 9.0 / 10.0 / 11.0 上是跑通过的，但版本往上走，console 认证失败后落到 shell 的行为在后续版本里被收紧了。具体表现是：认证失败后回到login:循环，不再给维护 shell，或者给的 shell 权限受限到无法执行tmsh。这时候硬套老流程只会浪费时间。

遇到这种情况，正确的方向是查对应版本的管理手册里"root 密码恢复"章节，通常走的是从安装介质引导进入单用户或救援模式、挂载配置分区、直接修改认证数据库这条路，步骤更长、风险更高，必须在维护窗口里做，而且要先备份配置。判断自己该走哪条路的信号很简单：console 认证失败后有没有#。有，走本章流程；没有，不要恋战，直接切方案。

4. 避坑与排查：五个真实翻车现场

这一章是我这些年攒下来的错题本，每一条都对应一次现场事故或者一次被网上文档带偏的经历。格式统一成"现象 → 原因 → 解决"，方便你出问题时对号入座。

4.1 照着文档敲 tshark，什么密码都抓不到

现象：按某份流传很广的文档操作，在 shell 里敲tshark，等了几分钟，除了滚动一堆抓包统计什么都没有，也没看到任何和密码相关的输出。

原因：tshark是抓包工具的命令行前端，它抓的是网络接口上的流量。而 console 会话根本不走网络接口，密码输入是本地 PAM 认证，明文既不落在网卡上也不落在任何可抓的链路上。那份文档里这一步本身就是错的，大概率是把tmsh误记成了tshark，再加上转手多次的文本粘连（原文里连波特率都被写成了19200Tmsh，明显是 OCR 或复制粘贴出的错），错误就这么传下来了。

解决：直接用tmsh进配置 shell，跳过任何"抓包找密码"的念头。密码不在流量里，它在认证数据库里，你要做的是覆盖它，不是找回它。

注意：网上流传的这类文档，凡是出现"抓包获取密码""用某工具嗅探密码"的描述，基本可以直接判定为错误或过时，不必浪费时间验证。

4.2 HA 双机只改了一台，同步后密码又不对了

现象：主设备密码改完、重启、登录正常。过了半小时做配置同步，再登录备设备，发现密码还是旧的；或者反过来，同步之后主设备的密码被备设备的旧值覆盖。

原因：用户账户和认证配置属于会被同步的配置项。双机场景下只改一台，另一台的旧配置在同步时会把新值顶回去，具体谁覆盖谁取决于同步方向。

解决：两台都要改，而且要在同步之前各自改完。操作顺序是：先在主设备上做完恢复流程并保存，确认能登录；再对备设备重复一遍完整流程；两台都确认新密码可用之后，再做一次配置同步，验证同步后密码一致。如果设备数量更多，就逐台过一遍，别指望同步能帮你传播密码。

4.3 改完直接 reboot，重启后密码回退

现象：命令都执行成功了，modify auth password root也提示修改完成，直接reboot，重启后用新密码登录失败，旧密码也不对。

原因：modify改的是运行配置（running config），没有落盘。重启时设备从持久化配置加载，运行配置里的改动全部丢失。

解决：modify之后必须执行save sys config，看到保存成功的回显再退出。养成习惯：任何modify类命令后面紧跟一条save，中间不插别的操作。这个坑我踩过一次，多花了四十分钟重来一遍。

4.4 密码复杂度策略把新密码拦下来了

现象：modify auth password root执行后报错，提示密码不符合策略，或者命令直接失败退出。

原因：设备上配置了密码复杂度策略（最小长度、字符类别要求、历史密码不可复用等），新密码没达标。这类策略在tmsh里可以查：list auth password-policy，能看到当前的约束条件。

解决：按策略要求构造密码，长度和字符类别都要满足，并且不要和最近几次用过的密码重复。如果策略要求过于严格导致无法构造，先确认是否有权限临时调整策略——但这属于配置变更，要走审批，不要在恢复流程里顺手改安全策略。

4.5 console 认证失败后没落到 shell

现象：输错密码，屏幕回到login:，反复几次都一样，拿不到#。

原因：版本行为差异，或者设备的 console 访问策略被收紧过。前面 3.5 节说过，新版本不再默认给维护 shell。

解决：不要再在 console 上试密码了，转去查该版本手册里的 root 密码恢复流程，走安装介质引导的路径。同时确认一件事：这台设备的 console 口访问是不是被人为加固过，如果是，说明有人做过安全基线，恢复流程的审批链要相应升级。

5. 验证与收尾：三路登录、日志留痕与 HA 一致性

改完密码、重启完成、看到login:提示符，很多人到这儿就收工了。但密码恢复是管理面变更，验证做得不扎实，问题会在几天后以另一种形式冒出来。这一章给一套我自己固定执行的收尾动作。

5.1 三路登录逐一验证

至少验证三条路径，缺一条都算没验完。

第一条是 console 本地登录，用新密码登录 root，进去之后id确认权限，再exit退出。第二条是 SSH，从一台管理网内的跳板机连过去，验证 admin 或 root（取决于设备是否开放 root 的 SSH 登录，多数默认关闭）能连上。第三条是 Web 配置界面，用 admin 登录，确认能进到主界面、能打开系统信息页。

三条都过，才说明密码在认证数据库、SSH 服务和 Web 服务三个层面都生效了。只验一条就收工，常见后果是 Web 能进但 SSH 报认证失败，回头再查会发现是某个服务缓存了旧的认证状态，得再重启一次。

5.2 日志与审计留痕

密码恢复必须在日志里留下痕迹，这不是可选项。设备侧的登录和认证事件记在/var/log/secure一类的系统日志里，配置变更记在审计日志里。恢复完成后，把相关时间段拉出来看一眼，确认操作记录完整，然后把日志片段附到变更单上归档。

# 查看最近的认证相关日志，确认登录和密码修改事件有记录 tail -100 /var/log/secure # 按关键字过滤，定位本次操作的时间窗口 grep -i "password\|auth" /var/log/secure | tail -50

这两条命令在 root shell 或 tmsh 的 bash 环境里都能跑。过滤结果里应该能看到本次操作时间点附近的认证成功、失败记录，以及tmsh的配置变更条目。日志缺失本身就是个信号，说明日志服务可能没在正常写，得单独排查。

提示：审计留痕不只是为了合规。真出问题时，日志是唯一能还原"谁在什么时间改了什么"的东西，比任何口头回忆都可靠。

5.3 HA 场景的密码一致性与同步验证

如果是双机或集群，收尾动作还要多一步。两台都改完之后，执行一次配置同步，同步完成后再分别登录两台设备验证密码一致。这一步不能只看同步命令的回显，要实际登录。我遇到过同步显示成功、但备设备的认证服务没重载、登录仍然失败的情况，最后是单独重启备设备解决的。

验证清单整理成一张表，照着走一遍：

表里任何一项没过，都不要关单。

5.4 把新密码纳入凭据管理

最后一步是流程上的。新密码设置完成之后，立即录入凭据管理系统或者封存到密码信封，写清楚设备标识、账户、修改时间、操作人和变更单号。我见过最离谱的一次是密码改完只记在工程师的个人笔记里，人一休假，设备又变成黑匣子，两周后同样的流程又走了一遍。

凭据管理这件事看着琐碎，但它是密码恢复流程真正的终点。没做这一步，等于把下一次事故的引信留在了原地。

6. 无物理接触时的替代路径与一条操作纪律

现实里总会遇到拿不到 console 的情况：设备在异地机房、代维方不配合、或者干脆没人能到现场。这时候要先把期望值降下来——前面那套流程的前提就是物理接触，没有这个前提，任何"远程破解密码"的说法都值得怀疑。可行的替代路径有三条，按优先级排。

第一条是带外管理通道。多数中高端设备配有独立的管理口或者接了 KVM/IPMI 一类的带外设备，如果有，等于把 console 延伸到了网络上，操作流程和现场完全一致。检查带外管理是否可用，比琢磨怎么绕过认证要高效得多。第二条是从 HA 对端入手。如果双机配置同步正常，对端的认证配置和本端是一致的，从对端的管理面可以下发配置变更，包括重置账户密码。这条路径要求对端健康且你有对端的访问权限，操作前先确认同步状态，别在配置不一致的情况下硬推。第三条是恢复介质引导，也就是前面提过的从安装介质进单用户或救援模式，直接改认证数据库。这条路最长、风险最高，必须安排维护窗口、提前备份配置，并且接受"恢复后可能需要重新校验配置完整性"的代价。

不管走哪条路，有一条纪律我这些年一直在守：任何密码恢复操作，先在纸面或者文档里把完整命令序列写一遍，包括每一步的预期输出和失败时的回退动作，然后再动手。听起来很笨，但它救过我至少两次——一次是在 HA 环境里差点漏掉备设备，一次是在save之前差点习惯性敲了reboot，都是因为提前写下来了才在最后关头停住。

从那以后我每次碰 console 线，都会先把三件事默念一遍：授权有没有、备份做没做、save 敲没敲。这三个动作加起来不到五分钟，但省下来的返工时间以小时计。希望帮到你。

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