企业官网建设流程全解析

简介：这份F5 BIG-IP密码恢复文档面向网络运维与系统管理人员，聚焦Ver9.0、10.0、11.0版本下因遗忘管理员密码导致控制台无法登录的应急处置场景，适合具备设备物理访问或控制台连接条件、需要按流程恢复访问权限的读者参考。压缩包仅含1个docx文件，大小约92KB，篇幅集中，内容围绕SecureCRT、PuTTY等终端工具连接、19200波特率参数、TCL交互环境及tmsh密码修改命令展开，并覆盖配置保存、退出与重启生效等关键环节，便于快速定位所需命令。文中还附有F5官方解决方案链接、指定版本测试说明和操作注意事项，便于读者在应急恢复时对照命令、核对版本范围并规避误操作风险。已有537人学习，说明该主题在运维实践中具有一定关注度，可作为密码重置流程清单与命令速查文档使用。

1. 一根串口线救回来的设备：F5 密码恢复到底卡在哪

一台在机房里跑了七八年的 BIG-IP，admin 密码跟着上一任运维一起离职了。Web 管理页面打不开，SSH 也进不去，最后能用的只剩一根 console 线和一台笔记本，串口速率 19200。这种情况下谈 F5 密码恢复，命令本身其实只有三四条，真正让人卡住的从来不是命令：你有没有物理或带外权限，设备到底是 9.0、10.0 还是 11.0，以及手上那份 2014 年流传下来的笔记有没有在转贴过程中被换行粘坏。我见过不止一个人对着tshmdify auth password root这种半截命令敲了一下午，报错一路到底，最后误以为是版本不兼容。下面把这条链路从头到尾走一遍，顺带把原始笔记里被吃掉的那一环补上。

2. 先分清场景：什么情况下只能走控制台恢复

2.1 三条入口的分岔：Web、SSH、Console 各自的前置条件

密码“丢”这件事有很多种丢法，处理路径完全不同，动手前先花两分钟分类，能省掉后面两小时的返工。第一种是主账号忘了但还有备用账号，比如另一个具备 Administrator 角色的本地用户，或者接入了远程认证服务器；第二种是本地账号全废但设备还活着，能做的是让别的运维从跳板机借一个有权限的会话进去改；第三种就是最惨的，本地账号全废、远程认证服务器也没配、还没有人保留会话，这时候唯一的路就是摸到设备跟前，插串口。

判断顺序我一般这么走：先确认有没有第二个人能登上 Web 控制台，有就不用折腾控制台；再确认设备组里有没有对端，能不能从对端拿配置；最后才落到 console。千万别一上来就奔机房，生产设备一旦进入重启流程，业务中断的时间窗口是要报备的，能不动就不动。

带外管理这条容易被忽略。很多部署在托管机房的设备，其实前面挂了一台串口服务器或者服务器管理卡，能从办公网直接连到 console 口，这种情况下不用真去机房。我一般先问一句“这台机器有没有远程带外”，答案往往决定整件事是半小时还是两天。

2.2 物理与带外权限是硬门槛，串口参数只有一套

F5 BIG-IP 的 console 口是标准串口语义，参数基本没有商量余地：速率 19200，8 位数据位，无校验，1 位停止位，无流控，终端类型按 VT100 或 VT100 兼容走。速率不是 9600，这一点跟很多网络设备不同，第一次接触的人容易照着习惯拨到 9600，然后在屏幕上看一屏乱码，怀疑线坏了。

在 Linux 或 macOS 上，不一定非要装 SecureCRT 或 PuTTY，screen和minicom都能干这活，还省得配一堆图形界面选项：

# Linux/macOS 下直接打开串口，19200 8N1 # 注意：先确认设备名，插拔 USB 转串口后通常是 ttyUSB0 或 tty.usbserial-xxxx screen /dev/ttyUSB0 19200 # 如果 screen 提示权限不足，把当前用户加进 dialout 组再重新登录 sudo usermod -aG dialout "$USER" # 退出 screen 的会话：先按 Ctrl+A，再按 K，然后确认

上面这段只有三件事：设备名、速率、退出方式。真正的坑在设备名——多插一个 USB 转串口，编号就从 ttyUSB0 变成 ttyUSB1，敲错设备名不会报错，只会看到一片空白或者乱码。另一种坑是流控，图形界面里“硬件流控”默认勾上的情况并不罕见，勾上之后现象是能连上、能看到登录提示符、但键盘输入没反应或者丢字符，很多人会误判成设备卡死。

线序也值得单说一句。RJ45 形态的 console 口不同厂商的针脚定义不一样，随手拿一根直通网线接上去，运气好能用，运气不好就是完全没输出，而且这种“完全没输出”跟设备断电、串口坏了的现象一模一样，排查顺序很容易跑偏。稳妥做法是用设备自带的原装 console 线，或者用明确标注了针脚定义的转接头。

2.3 版本边界：9.0、10.0、11.0 的共同点和差异点

原始笔记明确写了适用 Ver 9.0、10.0、11.0，且三个版本都实测通过。这个版本区间值得说清楚，因为它跨了 BIG-IP 从“两套配置体系并存”到“tmsh 成为唯一主入口”的过渡期。

三个版本的共同点比差异点更重要：都能通过 console 进入引导层，都能在单用户模式下拿到 root shell，都支持modify auth password这一族命令来改密码，都有save sys config做持久化。差异主要在引导菜单的样式细节和 tmsh 子命令的完备程度上，对“把密码改回来”这个目标影响不大。

真正需要警惕的是版本跨度带来的心理错觉。有人在一台 11.x 上跑通了，转头去一台 9.0 上照抄，发现某些 tmsh 子命令的补全行为不一样，就判断“方法只对新版本有效”。实际上改密那几条命令在三个版本上是同一套语义，跑不通多半是提示符层级搞错了，而不是版本不支持。

3. 复现路径：从 console 到 tmsh 的完整链路

3.1 连接阶段：先把“看得见提示符”这件事做扎实

链路的第一步不是敲命令，是确认你看到的提示符是真的。正确连上之后，屏幕应该出现设备的登录提示，通常形如login:。如果看到的是持续滚动的乱码，百分之百是速率或流控不对；如果看到的是登录提示但敲键盘没回显，先检查线序和流控；如果反复出现启动日志然后停在某个位置，说明设备本身在重启循环，那是另一个问题，别在这里改密码。

我一般会做一个小动作确认输入通道是双向的：在login:提示符下随便敲几个字符回车，看设备是否回一句认证失败。只要能回，说明串口收发都正常，后面所有问题都是命令层面的问题，范围立刻收窄。

还有一点是终端软件的回滚缓冲。SecureCRT、PuTTY 都能设置行数，默认值往往不够。单用户模式的启动日志很长，改密过程中的报错也常常一闪而过被日志冲掉，把回滚行数拉到几千行，等于给自己留了事后取证的余地。这个设置不起眼，但出问题时能省掉一次重启。

3.2 补上原始笔记缺的一环：怎么先进到 root shell

原始笔记从“console 连接”直接跳到了tmsh modify auth password root。这个跳跃是有前提的：你得已经在能执行 tmsh 的会话里。而现实是，密码忘了的时候，你连登录都过不去。所以中间缺的那一环，是把设备引导到单用户模式，先拿到一个不需要密码的 root shell。

常见做法是重启设备，在 GRUB 引导菜单出现时停下，编辑内核启动行，在末尾追加single参数，然后继续引导。整套动作在 console 上完成，不依赖任何网络服务。

# 1) 重启设备：console 上长按电源，或从带外管理卡发重启 # 2) 设备开机，GRUB 菜单出现时按任意方向键停住 # 3) 光标选中默认启动项，按 e 进入编辑 # 4) 找到以 linux 开头的那一行，在行尾追加 single linux /boot/vmlinuz root=/dev/sda2 ro quiet single # 5) 按回车返回菜单，按 b 用修改后的参数引导 # 6) 引导完成后会直接落到 root shell，不再询问密码 # 7) 单用户模式下根分区通常是只读挂载，先重挂为可写 mount -o remount,rw / # 8) 改 root 密码，按提示输入两次 passwd root # 9) 让系统正常走完初始化，或者直接重启 exec /sbin/init

第 4 步的single是整段的关键，它告诉内核只启动到单用户运行级，跳过所有需要认证的服务。第 7 步的mount -o remount,rw /同样不能省，只读挂载下改密码会报“无法写入”，报错信息还很含糊，容易被当成权限问题。第 9 步两种收尾方式有区别：exec /sbin/init是接着把剩下的服务拉起来，速度快但有可能留下半初始化状态；直接reboot更干净，代价是多等一次开机。生产环境上我更倾向后者，一次做干净，不给自己留玄学问题。

提示：单用户模式等于绕过了这台设备所有的身份校验，谁摸到 console 谁就能改密码。所以这条路径本身也说明了一件事：机柜锁和带外管理口的访问控制，才是这台设备真正的最后一道门。

3.3 改密阶段：root 和 admin 是两条独立命令

进到正常系统、用刚改过的 root 密码登录 console 之后，再进 tmsh 改应用层的密码。原始笔记里给的是这几条，我把它们还原成可执行的形态：

# 先进入 tmsh 配置模式 tmsh # 在 tmsh 提示符下修改 root 账号的密码，会提示输入两次新密码 modify auth password root # 修改 admin 账号的密码，推荐用 prompt-for-password 交互输入 modify auth user admin prompt-for-password # 另一种写法：直接把密码写在命令里（不推荐，见下） modify auth password admin # 改完保存配置 save sys config # 退出 tmsh quit # 重启让改动完全生效 reboot

关于modify auth user admin prompt-for-password和modify auth password admin这两条，原始笔记用“OR”并列，看起来等价，实际取舍不一样。prompt-for-password走交互提示，密码不进命令历史，也不会出现在 console 的屏幕回滚里；直接写密码那条，如果后面还跟了参数，密码就可能被记录到命令历史或者被旁边的人看到。我一般优先选前者，只有在需要脚本化批量处理的时候才考虑后者，而且那种场景下更应该走配置管理而不是手敲。

还有一点：改 root 密码和改 admin 密码是两件不同的事，做了前者不代表后者就好了。root 是 Linux 系统层的账号，用来进 bash；admin 是 BIG-IP 配置层的账号，用来登 Web 控制台和跑 tmsh。日常运维登的是 admin，所以密码恢复的最终目标通常是 admin，root 只是通往目标的手段。这个区别在原始笔记里没有展开，但它决定了你改完密码之后能不能真的登进去。

3.4 保存与重启：两种 save 写法的真实差别

save /sys config和save sys config在原始笔记里也是并列关系，很多人以为随便挑一个。实际上这两种写法跟你在哪一层提示符下有直接关系：

# 场景一：已经在 tmsh 提示符下（提示符形如 tmsh (active)(/Common)(tmos)） save sys config # 场景二：还在 bash 里，没进 tmsh tmsh save sys config # 在 tmsh 里用路径式写法也能被接受，等价于 save sys config save /sys config

差别在于save是 tmsh 的子命令，不是 bash 命令。在 bash 里直接敲save sys config会得到 command not found，而很多人这时候会误以为“保存命令在这个版本不支持”，转头去重启，结果改动全丢，第二天密码又不对了——这种隔夜返工最伤士气。

保存之后再reboot，是让改动彻底落到运行时状态。严格来说改密不一定需要重启，save sys config之后新密码就已经生效了，重启只是让所有服务重新读一遍配置，避免某些进程还挂着旧凭据。原始笔记把 reboot 列为最后一步，我认为在密码恢复这个场景下是合理的，因为你要验证的是“开机之后还能不能登进去”，而不是“当前会话里能不能用”。

4. 命令背后的原理：为什么这么改才生效

4.1 root 与 admin：两套账号体系别混着看

BIG-IP 的账号模型比一般网络设备复杂一层。root 是底层 Linux 的超级用户，能进 shell、能看文件系统、能启停服务；admin 是 BIG-IP 自己的配置层用户，归属于某个管理分区，拥有某组角色权限，日常配置、Web 登录、tmsh 操作都是这个体系。设备出厂时两者往往用同一套初始凭据，时间一长就被人为分开了：有人定期改 admin 的密码走密码管理系统，root 的密码却还停留在装机那天，反过来也有。

这个分裂直接决定了恢复策略。如果只是 admin 忘了、root 还记得，那根本不用进单用户模式，console 上用 root 登录，进 tmsh 改 admin 就行，五分钟的事。如果两个都忘了，才需要走 3.2 那一步。反过来说，如果只改了 root 密码就以为完事，重启之后你会发现 bash 能进、Web 还是登不上——因为 Web 认的是 admin。

权限模型还有一层：admin 账号可以被授予“高级 shell”权限，授予之后它也能进 bash。这时候 root 和 admin 的边界看起来模糊了，但配置文件里的账号记录还是分开的两条，改一条不会动另一条。我一般会建议客户在恢复完成之后，明确记录清楚哪些账号有 shell 权限，别让下一任运维再猜一遍。

4.2 tmsh、tclsh 与那个被误传的 tshark

三个名字长得很像，功能完全不同，但流传的笔记里经常被混着写，这是我认为最值得单独拎出来讲的一节。

tmsh 是 Traffic Management Shell，BIG-IP 的配置命令行，改密码、改虚拟服务器、存配置都靠它。tclsh 是 TCL 解释器，BIG-IP 内部大量脚本用 TCL 写，进 tclsh 之后可以执行 TCL 语句，也可以借exec调系统命令，属于更底层的手段。tshark 是 Wireshark 的命令行抓包工具，跟 BIG-IP 的密码恢复没有任何关系。

有些流传版本里会写“用 tshark 抓 console 通信找密码”，这个说法是错的，而且错得有害。抓包看不到明文密码，远程登录走的是加密通道，console 上的交互也不是靠抓包能还原的；更要紧的是，照着这个说法去折腾抓包，会把人从正确的路径上带偏，浪费掉本来就很紧张的维护窗口。原始笔记正文里并没有这一段，是后来转述时加进去的，属于典型的“二手加工污染”。

还有一个更隐蔽的污染是换行粘连。原始笔记里tmsh modify auth password root这条命令，在两个词之间被断行了，转成纯文本之后变成tshmdify auth password root。这条命令敲进去必然报错，报错信息又不指向真正原因，新手很容易在这里卡住。看到长得很奇怪的命令名，先怀疑一下是不是被断行粘坏了，把常见的子命令前缀拆开试一遍，往往一眼就能还原。

4.3 save sys config 究竟写了什么

配置保存这件事值得讲透，因为它决定了你的改动是“活过一次重启”还是“活到下次重启”。

BIG-IP 的配置分运行配置和存储配置两层。你在 tmsh 里敲的每一条命令，先改的是运行态，进程立刻按新配置工作；只有执行save sys config，才会把运行态写进磁盘上的配置文件，同时生成一份带时间戳的备份。不保存就重启，设备从磁盘读配置，你刚才的改动全部消失，现象就是“改完明明能登，重启后又不行了”。

这个机制在设计上是保护性的：改错了不保存，重启就能回滚，相当于自带后悔药。但在密码恢复场景下它是个陷阱，因为人容易在改完密码、验证成功之后就急着退出，忘了最后那一条保存。我现在的习惯是改完密码先不验证，先把save sys config敲了，再退出重登验证，顺序反过来能避免绝大部分“改了没生效”的困惑。

备份文件的价值在出问题时才显现。如果保存之后发现改错了账号、锁死了某个管理入口，理论上可以从备份恢复，但那属于另一个量级的操作，风险比改密码高得多。所以更实际的做法是：动手之前先确认有没有可用的配置备份，没有的话，至少把当前能登的会话保持住别断，留一条后路。

5. 排查与避坑：五次返工换来的检查清单

5.1 连接和引导阶段：三次当场翻车

现象一：串口连上满屏乱码，偶尔能辨认出几个字符。原因基本锁定在速率和流控上，19200 拨成 9600、或者图形终端里硬件流控没关，都会产生这种半可读的乱码。解决是把参数严格对齐 19200/8/N/1、流控 None，重连一次；如果换参数后依旧乱码，再怀疑线序，换原装 console 线复测。这一步不要靠猜，参数表就六行，逐项对一遍比反复试快得多。

现象二：能看到登录提示符，键盘输入却像石沉大海。这种现象跟“设备卡死”高度相似，实际上多数是终端软件的本地回显没开，或者串口线只通了接收方向。判断方法是看设备侧有没有反应：随便敲几个字符回车，如果设备回一句认证失败，说明发送通道是通的，问题在本地显示；如果设备毫无反应，才是链路问题。把本地回显打开、换一根确认好的线，两个动作就能定位。

现象三：GRUB 菜单一闪而过，根本来不及按 e。原因是引导等待时间被设得很短，或者有人在 console 上按了重启之后就去干别的了。解决办法是在设备重启的瞬间就开始连续敲方向键或者空格，抢占那个等待窗口；如果实在抢不到，可以在带外管理卡上操作，因为带外通常能看到完整的 POST 过程，反应时间更充裕。这一条纯属手速和注意力问题，但翻车率不低。

5.2 改密和保存阶段：两次隔夜返工

现象四：照着笔记敲tshmdify auth password root，报 command not found。原因就是前面说的换行粘连，原始命令tmsh modify ...被断成两截粘在了一起。解决办法是把前缀拆开，先在 bash 里敲tmsh进配置模式，再敲modify auth password root；或者一行写完tmsh modify auth password root。判断依据很简单：如果报错说找不到命令，而你确认自己没打错，先怀疑命令本身被加工过，而不是怀疑设备不支持。

现象五：改完 admin 密码，当场验证能登，第二天早上又登不上了。这是最典型的“没保存”或“保存层级错了”。原因有两种：一是在 tclsh 或者 bash 里敲了save sys config，命令根本没被执行；二是改完密码直接拔线走人，save那一步压根没做。解决办法是改密之后立刻在 tmsh 提示符下执行save sys config，看到明确的保存成功回显再退出；随后主动重启一次，用重启后的登录验证作为最终确认，别拿当前会话的成功当结论。

现象六（顺带补一条）：改完密码登录正常，但对端设备告警、配置同步异常。原因是这台设备处在设备组里，本地账号改动没有同步到对端，或者两端账号密码不一致导致同步认证失败。解决办法是在维护窗口内操作，改完一台之后立刻在设备组层面同步一次，或者对端也走一遍同样的恢复流程；如果暂时不具备条件，至少先把同步相关的告警压住，别让它在业务高峰自己冒出来。这一条不影响单机恢复，但影响恢复之后的稳定性，容易被忽略。

注意：上面六条里，真正会造成“业务二次中断”的是最后一条。密码恢复只影响管理面，配置同步异常却可能动到业务面，动手前先确认这台设备在不在设备组里。

6. 最后落到一份可执行清单：改完密码之后还要做什么

密码改回来只是把门重新打开，门后面的东西有没有被动过、下次会不会再丢，是另一件事。我现在的做法是把它当成一次小型的变更来收尾，固定走一遍下面这张表：

这张表里最容易被跳过的是“重启验证”，因为它多花五分钟，而当场登录已经成功了。但那五分钟恰恰是区分“改好了”和“以为改好了”的唯一标准，我自己就在这上面栽过——某次改完密码顺手清了会话，第二天早上被电话叫醒，说 Web 登不上，到现场一看，配置文件时间戳还停留在前一天下午，save那一步被我自己漏掉了。

从那以后我每次做密码恢复，都强制走一遍“改密 → save → 重启 → 重登”这四步，不管当时多赶时间，也不管当场验证看起来多成功。这套动作在 9.0、10.0、11.0 上都是一样的，版本差异影响的是引导菜单长什么样，不影响这四步的顺序。真正需要提前准备的，是那根 19200 的串口线和一次可以接受的维护窗口，其余都是照着敲的事。

还有一个小技巧送给要重复做这件事的人：把 console 会话的回滚缓冲拉到最大，改密过程中所有的回显都留着，做完之后截一张完整的会话图存档。下次再有人问“这台设备当时是怎么恢复的”，你不用回忆，直接翻记录。密码这种事，后悔药是提前备好的，不是事后找的。希望帮到你。

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