接手一批二手设备或者别人留下的机房时我第一件事往往不是看 zone 配置而是先把本地账号数一遍。光纤交换机Fibre Channel Switch下文简称 FC 交换机这类设备有个特点它们不直接对外提供服务日常没人碰装进机柜之后可能三五年只被动过两三次于是出厂时那套通用账号就一直躺在配置里。等到验收、等保测评、内部审计翻出这一条往往已经是一批设备、好几个 fabric 同时要处理还得排变更窗口。这篇就聊透“把 FC 交换机的默认口令改掉”这件事本身它到底在防什么、改之前要盘哪些东西、单台怎么改、几十台怎么批量改、改完登不上怎么救以及怎么让这件事不随着人员流动再退回去。刚接手 SAN 运维的人可以照着走做过几年的也能在里面找到几个容易翻车的点。1. 默认账号在FC交换机上为什么是高优先级问题1.1 一条链路背后的资产盘子比看上去大很多人对 FC 交换机的直觉是“它就是个二层转发盒子”风险有限。这个判断在物理隔离做得很彻底的环境里勉强成立但只要管理网和办公网有那么一跳可达结论就反过来了。FC 交换机是 SAN 的控制面zone 怎么划、哪些主机能看见哪些 LUN、端口是否隔离全在这台设备上。拿到管理员权限的人不需要碰任何一台服务器只要改一条 zone让一台本不该看见存储的主机看见生产库的卷剩下的就是时间问题。更麻烦的是这类操作在存储侧往往只体现为“某个 WWN 上线了”日志里并不刺眼。所以默认口令这件事在 FC 交换机上的权重和在一台接入层以太网交换机上完全不是一回事。后者被登进来顶多多划一个 VLAN前者被登进来可能直接动到核心业务的数据可见性。我在排变更优先级时会把“仍在使用出厂通用账号的 FC 交换机”放在和“存储阵列管理口暴露”同一档而不是跟普通网络设备放一起。还有一层常被忽略FC 交换机的配置里通常存着 fabric 的全部成员信息、别名库、以及与其他交换机的链路参数。这份配置本身就是一张高价值的拓扑图。配置备份文件如果落在一个人人可读的 TFTP 目录里等于把整张 SAN 地图公开了而备份任务用的账号八成就是那个没改过的默认账号。1.2 三条现实风险路径从默认口令到生产中断第一条路径是通用账号被直接撞开。出厂账号的用户名往往是固定的几个词口令在不同批次设备上高度相似甚至和序列号、机型有可推导的关系。这类信息在公开渠道并不难找所以“没人知道我们有机房”不构成任何防护。设备只要有一次因为排查问题被临时接到管理网风险窗口就打开了。第二条路径更隐蔽辅助服务留了口子。不少 FC 交换机除了 CLI还开着用于配置上传下载的文件传输服务、用于监控的 SNMP、用于时间同步的 NTP以及早期固件里的 Web 管理页。这些服务各自有独立的认证配置其中 SNMP 的 community string 出厂常常就是public/private这种。攻击面并不在 SSH 上而在这几个没人管的旁路。做加固时如果只改了登录口令SNMP 那一项没动等于门锁换了、窗户还开着。第三条路径是内部合规与责任归属。这一条听起来不技术但实际最常触发整改。设备清单交接时如果没写清楚“默认账号已改、新口令存放在哪里”下一个接手的人为了进设备第一反应往往是找厂商支持或者翻旧文档而不是走正规的账号申请流程。几次之后账号体系就彻底乱了谁也说不清哪台设备上有几个活着的账号。1.3 动手前必须确认的四件事谁有权改。FC 交换机的用户管理通常只有最高权限角色能操作普通运维账号能看不能改。提前确认手上的账号属于哪一级避免变更窗口开了才发现权限不够。管理通道是否有备份路径。改口令的过程中最怕把自己关在门外。开工前确认带外 Console串口能连上、串口线在手边、终端参数记得住常见是 9600-8-N-1流控关。这一条看着啰嗦但它决定了下一条。是否有多套认证源。有些 fabric 接了集中认证本地账号只是兜底。这种情况下改本地口令对日常登录没影响但设备失联时会用得上仍然要改只是验证方式不一样。变更会不会影响自动化任务。监控采集、配置备份、性能报表、拓扑发现这些后台任务很可能各自存了一份设备凭据。口令一改它们会静默失败直到某天需要看历史曲线才发现断了几个月。这一条我吃过亏后面第 4 节会专门讲怎么处理。提示口令变更和 zone 变更不要放在同一个窗口。两类操作都会让设备重新计算配置出问题时你分不清是哪一步导致的。2. 改之前先把账号家底盘清楚2.1 三条登录通道怎么选FC 交换机通常有三条进入路径带外 Console串口、管理以太网口的 SSH/Telnet、以及通过 fabric 内其他设备跳转的带内管理。日常改口令我会优先走管理网 SSH因为可复制粘贴、能留会话日志、出错好回看但第一次碰一台陌生设备时我一定先确认 Console 通理由很直接SSH 依赖网络配置和认证服务都正常而改口令这个动作本身就有概率把这些搞坏。带内管理要慎用。它的可用性依赖 fabric 本身健康一旦改口令过程中触发了某条链路的重新协商会话可能直接断而这条会话正是你唯一的入口。如果只能走带内务必先确认另一台交换机的入口是通的别把自己锁在一个单点上。Telnet 这条通道的建议很简单确认它关着。有些固件默认开着 Telnet 服务用于兼容老旧管理工具口令在网络里是明文跑的改得再复杂也没意义。加固清单里把“关闭 Telnet、只留 SSH”和“改默认口令”放在同一批做成本几乎为零。2.2 用只读命令把本地用户、角色、服务列出来多数 FC 交换机的 CLI 会把用户管理收敛在user、passwd、audit、snmp这几个命令族下面具体参数名各厂商、各固件版本有差异动手前先跑一遍帮助命令看清楚。下面给的是结构示意实际敲的时候以设备自己的 help 输出为准# 命令族结构示意参数名以设备 help 为准 admin help # 先看有哪些顶层命令族 admin user --list # 列出本地账号、角色、状态 admin user --show 账号 # 看单个账号的详情角色、是否启用、最后修改时间 admin audit --show # 看审计日志配置与时间源 admin snmp --show # 看 SNMP 版本与 community 配置 admin service --status # 看待开放的服务ssh / telnet / http / ftp 等跑完这几条你应该能回答四个问题本地一共有几个账号、分别是什么角色、哪些还在启用状态、除了登录之外还开着哪些带认证的服务。这四个答案决定后面的工作量。我见过最夸张的一台设备上有七个本地账号其中三个是不同时期的集成商留下的名字还是test1test2这种谁也不敢删因为不知道删了会不会影响某个没人记得的脚本。盘账号的时候顺手做一件事把每个账号的用途标出来。能明确对应到人或者对应到具体任务的留下对不上的先禁用观察两周没人喊再删。禁用比直接删安全因为删了之后如果真有任务依赖它报错信息往往很含糊排查成本反而高。2.3 存一份改前快照这是唯一的后悔药改口令之前必须把当前配置完整导出一份并且这份文件要能被回灌。做法上先确认设备支持配置上传下载把整份配置拉到本地或者内网的文件服务器上文件名带上设备标识和日期。同时把刚才user --list、service --status、snmp --show的输出重定向存成文本这东西在出问题时比配置文件更好读。快照的关键不在于存在于验证它能用。我一般的做法是在一台非关键的设备上导出一份配置随便改个小参数再用备份回灌看设备是否完整恢复。这一步花十分钟但能避免在真正的变更窗口里发现“备份文件是空的”这种事故。备份文件是空的或者只有几行通常是因为传输过程被中断、或者文件传输服务的认证方式变了——这两种情况都很常见。另外提醒一句配置文件里通常包含加密后的口令字段但它不代表你能从里面还原出明文。所以快照是配置回滚用的不是口令找回用的。口令本身的保管要走另一套流程见第 4 节。2.4 角色与实际权限的对应关系FC 交换机的角色划分比以太网设备简单但边界要看清楚否则会出现“以为改的是只读账号结果改的是管理员”这类乌龙。角色类型典型能力改口令时的注意点管理员级全部配置、用户管理、固件升级、fabric 参数只有这一级能改别人的口令务必保留至少两个可用账号操作级zone 增删、端口配置不能碰用户体系常见于自动化脚本口令通常硬编码在脚本里只读级查看配置、状态、日志监控系统常用改完记得同步更新采集端配置服务/维护级厂商远程支持、诊断命令平时应处于禁用状态需要时临时开启并设到期时间辅助服务凭据SNMP community、文件传输账号不属于“用户”容易在盘点时被漏掉这张表的重点在最后一行。做账号盘点时如果只跑了用户列表SNMP community 和文件传输账号是看不到的得单独去查。我习惯把这两类和用户账号放在同一张台账里管因为它们本质上是同一类东西一组能让外部获得设备能力的字符串。3. 单台设备的改密全流程与验证动作3.1 交互式改密从登录到生效的每一步单台设备的口令变更我按固定顺序走不跳步。确认当前账号数量与可用性。至少确认除正在使用的账号外还有第二个管理员级账号处于启用状态。没有的话先建一个临时的改完再处理。这一步的意义是万一新口令敲错或者被策略拒绝你还有入口。确认配置已保存。改口令之前先存一次配置避免把之前遗留的未保存改动和本次变更混在一起。执行改密。口令修改命令通常分两种形态改自己的、改别人的。改自己一般是passwd这类命令会要求连输两遍新口令改别人的需要指定账号名且部分固件要求同时指定角色。立即验证新口令可用。不要关掉当前会话另开一个连接用新口令登录确认能进、角色正确。确认变更落盘。口令变更一般会即时写入但保险起见再存一次配置然后查看审计日志里是否有对应的记录条目。输入新口令时有两个细节容易被忽略。一是特殊字符的处理某些终端的键盘映射会让$、!、#这类字符在传输时变样你以为设的是Abc!23设备收到的是别的。二是长度上限部分固件对口令长度有硬上限超长部分会被静默截断你按长口令记登录时自然对不上。所以设完之后必须实际登一次这是唯一可靠的验证方式。3.2 密码策略不是可选项长度、复杂度、有效期怎么定只改口令不设策略等于白改——下一次有人图省事设回简单口令问题原样回来。策略项一般包含四块最小长度。FC 交换机的本地账号数量很少且不对外暴露长度可以设得比通用账号体系更保守16 位是很舒服的档位。字符类别。至少要求三类混合。要注意的是有些老固件对可用字符集有限制策略设得太严会导致“怎么设都不通过”先在测试机上验证一遍策略能不能被满足。有效期。这一项是双刃剑。设 90 天看起来很规范但如果没人盯着到期那天设备会把你关在门外而 FC 交换机的口令过期往往不会提前很久提醒。我的做法是有效期照设但在监控里加一条到期前 15 天的告警并且把这个告警的接收人写进值班表而不是挂在某个人的邮箱里。失败锁定。连续失败若干次锁定账号这个能挡暴力尝试但也会在你手抖的时候把自己锁住。锁定阈值和锁定时长要记进交接文档别等真被锁了才去翻手册。提示策略变更和行为变更分开做。先把策略定下来可能只影响新设的口令再逐台改口令这样出问题时能立刻判断是策略太严还是操作有误。3.3 改完必须做的三项回归验证改口令这个动作本身只要十几秒验证要花的时间是它的十倍但必须做。第一项新口令能登录且角色正确。用新口令从管理网 SSH 登一次执行一条需要写权限的只读命令比如查看 zone 配置确认没有权限报错。再用旧口令试一次确认被拒绝——这一条能验证变更真的生效了而不是被某个缓存或旧会话掩盖。第二项依赖该账号的自动化任务仍然正常。监控采集、配置备份、日志转发逐个手动触发一次或者等一个采集周期。配置备份这个最容易验证手动跑一次备份任务看生成的文件时间戳是不是当前的。如果任务是用旧口令的这里会失败而且失败信息往往只报“认证失败”不会告诉你是哪个账号。第三项审计日志里有记录。查看设备的审计日志确认这次口令变更留下了条目且时间戳与操作时间对得上。如果时间对不上说明设备的时间源有问题这会影响后续所有日志的可信度顺手把 NTP 配好。这一项在合规检查里经常被问到提前做掉省事。3.4 报错信息对照这几种提示分别意味着什么改密过程中的报错信息通常很简短含义需要经验补全。整理一张对照表放在手边比临时查手册快。现象/报错大概率原因处理方向提示口令不符合策略长度、字符类别或历史重复限制先看当前策略配置别反复试错触发锁定两次输入不一致终端字符映射问题不是手误换个终端或改用 ASCII 字符集内的符号提示权限不足当前账号不是管理员级换账号不要试图绕过修改成功但新口令登不上长度被截断或特殊字符被转义用不含特殊字符的长口令复测定位是哪一个因素修改后原会话被断开部分固件在口令变更后会强制重建会话属正常行为但要确认配置已落盘提示账号已锁定之前多次失败触发了锁定策略等待锁定时长结束或用另一管理员账号解锁这张表里最值得记的是第四行。“修改成功但登不上”是吓人程度最高的一类因为此时你可能已经把唯一的入口弄丢了。防它的办法只有一个改完立刻用另一个会话验证绝不先关当前会话。4. 几十台一起改批量作业的分级与脚本骨架4.1 先分级再动手单机→机柜→单fabric→双fabric批量改口令最容易犯的错是“一次性全推”。FC 环境的特点是冗余路径成对存在A、B 两个 fabric 互为备份同时改两边等于同时拆掉两条路。所以顺序必须是先在一台非关键设备上跑通全流程含验证和回滚确认命令、策略、脚本都没问题然后按机柜或按业务分组小批量推进每组不超过五台每批之后等一个完整的监控周期确认没有异常告警再按 fabric 推进先 A 后 B两边之间至少留出一个业务低峰期最后处理那些“不敢动”的设备——通常是核心 fabric 里最老的那两台它们的固件版本可能和别的不一样命令参数有差异要单独对待。这个顺序看着慢但它把“出事时的爆炸半径”控制在了可接受的范围内。真正的风险不在于改口令失败而在于改完之后某个依赖它的任务断了而你没在第一时间发现。4.2 脚本骨架读清单、连设备、改密、回写结果批量作业用脚本跑是合理的但脚本要做的不只是“连上去改一下”它得能留下可追溯的记录。下面是一个结构骨架用 Python 的 SSH 库实现重点是流程而不是具体命令# 结构示意批量改密的主流程骨架 import csv, logging, datetime from concurrent.futures import ThreadPoolExecutor def load_targets(path): 读取设备清单管理地址、账号、所属fabric、分组 with open(path, newline, encodingutf-8) as f: return list(csv.DictReader(f)) def change_password(host, user, old_pwd, new_pwd): 单台设备的改密动作返回结构化结果 result {host: host, status: unknown, detail: } try: # 1. 建立连接建议设置 15s 超时避免卡死整批任务 # 2. 执行改密命令逐条读取回显匹配成功/失败关键字 # 3. 新开一条连接用新口令登录验证 # 4. 保存配置 result[status] ok except Exception as e: result[status] failed result[detail] str(e) return result def main(): targets load_targets(devices.csv) # 并发数控制在 5 以内太多会让审计日志难以对应 with ThreadPoolExecutor(max_workers5) as pool: results list(pool.map(lambda t: change_password(**t), targets)) # 结果回写必须包含时间戳与失败原因 stamp datetime.datetime.now().strftime(%Y%m%d_%H%M) with open(fresult_{stamp}.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[host, status, detail]) writer.writeheader() writer.writerows(results) if __name__ __main__: main()几个实操层面的取舍值得说清楚。并发数不要开大FC 交换机的 CLI 会话处理能力有限同时连太多会出现“连上了但命令回显不全”的情况脚本误判为失败反而制造混乱。命令回显的匹配要用“成功关键字 失败关键字”双向判断只匹配成功会出现“实际失败了但脚本认为成功”的漏网。最容易被忽略的是第四步“保存配置”——有些固件改完口令不自动落盘设备重启后回到旧口令这种问题可能几个月后才暴露届时没人会想到是这个原因。4.3 千万别把密码硬编码进脚本和配置文件脚本里写明文口令是最常见的做法也是最不该做的。现实中我见过的替代方案有几种按落地难度从低到高一种是运行时交互输入。脚本启动时从标准输入读口令不落盘。缺点是没法定时跑只适合人工触发的批量作业而批量改口令恰好就是人工触发的场景匹配度很高。一种是外部凭据文件 严格权限。口令放在一个只有执行账号可读的文件里权限设成 600脚本运行时读取。这不完美但比明文写在代码里好得多因为凭据文件和代码可以分开管理、分开轮换。一种是接集中凭据管理服务。脚本向服务申请临时凭据用完即失效。这套东西搭起来成本不低适合设备规模大、有专门平台团队的环境。不管用哪种有一条是硬要求脚本产生的日志里不能出现口令。有些库在调试模式下会把完整的交互过程打印出来包括你输入的字符。上线前把日志级别调到生产级别并且搜一遍日志文件确认没有口令残留。4.4 变更窗口内的观察点与回滚预案窗口内要盯的东西不多但要盯对。第一是链路状态。改口令不应该影响任何端口状态如果发现某个 ISL 或设备端口出现异常立刻停止后续批次先排查。虽然理论上两者无关但变更窗口里任何异常都值得停下来看一眼因为后续批次会放大问题。第二是依赖任务的报错。窗口内主动去看监控平台、备份系统的任务状态别等告警自己冒出来。有些系统认证失败后会重试若干次真正报警可能是半小时后。第三是能不能回滚。回滚方式很朴素用另一个管理员账号登录把口令改回旧值。所以关键在于——旧口令在变更窗口内必须可获取。我一般的做法是把旧口令封在一个临时凭据里窗口结束后销毁。这个临时凭据的存在时间就是回滚窗口写进变更单。5. 改不动的那些情况从锁定到改完登不上5.1 默认账号被停用或锁死后的恢复路径有一种情况很尴尬上一任管理员为了“安全”把出厂账号禁用了但又没建替代账号或者替代账号的口令没人知道。这时候设备还能转发但你进不去。恢复路径按侵入性从低到高排先试其他管理员账号再试通过 fabric 内其他设备的带内通道跳过去前提是那台设备权限够再试 Console 口——Console 通常不经过账号认证体系的某些环节但大多数 FC 交换机的 Console 仍然要求登录所以它解决的是“网络不通”而不是“口令忘了”。真正忘干净了剩下的路径通常是走厂商的恢复流程可能涉及设备重启进入特殊模式、配置被清空。这意味着设备的 zone 配置、别名库全部丢失需要从备份回灌。这条路径的存在反过来证明了第 2.3 节那份配置快照的价值。同时它也给了一个明确的管理要求任何一台生产 FC 交换机必须有两个口令不同的管理员账号且两个口令分别由不同的人保管。单点保管的账号体系早晚会在这个环节上出事。5.2 改密瞬间会话被踢掉的真实原因改完口令当前会话断开多数固件的行为是正常的——它会重建会话以确保新凭据生效。但有两种“断开”是不正常的。一种是断开之后再也连不上。原因通常是口令里包含了终端或设备无法正确处理的字符导致实际生效的口令和你以为的不一样。也可能是长度超限被截断。这两种情况都指向同一个教训口令字符集要保守。我现在的习惯是只用大小写字母、数字和两三个确定安全的符号长度控制在策略上限以内宁可牺牲一点熵也不用那些容易出问题的字符。另一种是断开之后设备重启了。这种情况少见但存在往往和固件版本有关口令变更触发了某个已知问题。所以变更窗口内要确认设备的运行时间uptime如果发现重启后续批次要暂停先评估这个固件版本是否适合这次变更。5.3 双fabric只改了一半会怎样A fabric 改完、B fabric 还没改这中间的时间差里环境的实际状态是“一半设备用了新口令一半还是旧的”。这个状态本身不影响 fabric 工作但会给运维带来实打实的麻烦值班人员手上的凭据可能只对一半设备有效故障排查时按旧文档登录会失败误判为“设备失联”。处理办法是在台账里显式标注状态。每台设备加一个字段记录“口令版本”和“最后变更时间”一半改完的时候台账能立刻看出哪些是新的哪些是旧的。这个字段看着笨但它是唯一能让多人协作时不混乱的东西。台账放在共享位置变更人改完立刻更新不要等到全部结束再统一填——因为“全部结束”往往拖好几天。5.4 人员交接和文档断层带来的二次事故这一条不是技术问题但它造成的故障比技术问题多。典型场景改口令的人离职或者转岗新口令存在他的个人密码本里接手的人进不去设备找厂商重置配置被清空zone 全丢从备份恢复又发现备份用的是旧固件版本的格式。防它的办法是把“口令变更”当成一次有交付物的变更来管理变更有记录、新口令进入统一的保管位置、台账同步更新、回滚方式写在变更单上。听起来重但把这几件事做成模板之后每台设备多花不了一分钟。6. 把默认口令这件事长期摁住6.1 周期性核验巡检表里该放哪几项一次性改完只是开始。设备会新增、固件会升级、集成商会来调试每一个动作都可能让默认账号重新出现。所以要把核验做进周期性巡检里而不是当成一次性项目。巡检项检查方法异常判定本地账号清单列出账号名与角色出现通用默认名、test类命名、来源不明账号账号启用状态查看每个账号是否启用存在长期未使用但启用的账号口令最后修改时间查看账号详情超过策略有效期仍未变更密码策略配置查看策略项长度、复杂度、有效期被改回宽松值SNMP 配置查看版本与 community仍使用出厂默认字符串或使用 v1/v2c开放服务查看服务状态Telnet、HTTP、文件传输服务处于开启状态配置备份任务手动触发一次备份文件时间戳不是当前说明凭据已失效审计日志时间比对设备时间与标准时间偏差超过阈值说明时间源未配置这张表按季度跑一遍工作量大概是每台设备几分钟。跑的时候顺手把输出存下来几次之后就有了历史对比能看出哪些设备在被反复“改回去”。6.2 与审计/堡垒机对接时容易忽略的细节把 FC 交换机纳入统一的运维审计体系是好事但有几个细节不处理会带来新问题。一是账号映射。堡垒机里配置的设备账号如果还是旧口令纳管之后所有会话都失败。变更口令的流程里必须包含“同步更新堡垒机上的设备凭据”这一步而且要在变更窗口内做不能等到事后。二是会话录制对交互式命令的影响。改口令是交互式输入某些审计模式会对输入内容做脱敏或者拦截导致命令没被正确执行。变更前先在一台设备上验证一遍全流程能不能走通。三是审计日志本身的留存。设备本地的审计日志容量有限写满之后会覆盖旧的。如果要满足留存要求得配日志外发。这一项和口令变更经常一起做因为都要动配置但要注意别在同一个窗口里同时改否则出问题不好定位。6.3 新设备上线流程里加一道闸最后落到流程上。默认口令这个问题之所以反复出现根子在“新设备上线”这个环节没人管。设备到货、上架、配置 zone、接入监控一路走完唯独没人想起改口令因为这一步不在任何人的清单里。解法很土但有效在上线检查表里加一行硬性项——“本地账号已盘点、通用默认账号已处理、口令已入统一保管、台账已更新”并且要求填写账号清单的输出作为凭证。没有这一行验收不通过。这一行的成本是十分钟它挡掉的是未来某次审计里的一整批整改项。我自己在这件事上的体会是改口令本身的技术难度几乎为零难的是让它成为一件有记录、可追溯、不依赖某个人记忆的常规动作。凡是靠“记得去改”的事情在人员流动面前都撑不过两年。真正管用的不是更复杂的策略而是把动作固化进流程、把状态写进台账、把核验放进巡检。这三件事做到位默认账号这类问题就基本不会再冒头了。