1. 光纤交换机默认口令，比你想的更要命

干过机房的人大概都有这么一段经历：接手一批设备，翻出交接文档，上面端端正正写着管理地址和一句"口令未修改"，然后你连上去一看，账号admin，口令还是出厂那个。前不久我就碰到一台光纤交换机（SAN 交换机）是这个状态，设备上跑着两套存储的核心链路，而它的管理口令，从我入职那天到现在，一个字没动过。这就是"光纤交换机默认密码更改"这件事之所以值得单独拎出来讲的原因——它不是一条命令的事，而是一整套从识别风险、确认管理面、执行变更到防止把自己关在门外的流程。

这篇文章面向三类人：刚接手 SAN 环境、需要把设备基线收干净的运维；被安全审计指着鼻子要求整改的设备管理员；以及拿到二手交换机、准备上架但不确定前任留了多少后门的工程师。我会把默认口令的风险面、账号角色模型、改密实操、批量执行顺序、翻车后的排查路径完整拆开讲，命令给到可以直接抄的程度，同时把"为什么这么干"讲透。看完你至少能做到：知道这台设备上有几个默认凭据入口，知道改哪几个，知道按什么顺序改不会断业务，也知道万一改完登不上去该从哪查起。

先说结论：光纤交换机的默认口令问题，绝大多数时候不是"改一个 admin 密码"就完事，而是涉及 CLI 账号、Web 管理界面、SNMP 团体字、以及各类出厂预置账号的一整片攻击面。只改 admin，等于给大门换了锁，窗户还开着。

1.1 一台设备的默认账号，等于整个 fabric 的钥匙

光纤交换机和普通以太网交换机最大的区别在于它的位置。它不参与三层转发，也不是办公网的边缘接入，它蹲在存储和主机之间，是整个业务数据通路的咽喉。一台交换机上挂着十几台服务器、两套存储阵列、若干条 ISL 级联链路，它的 zone 配置决定了谁能看到谁。换句话说，拿下这台交换机的管理权限，等于拿到了整个存储网络的拓扑图、在线状态和配置能力。

默认口令的危害在这里会被放大。攻击者不需要做复杂操作，一条 zone 变更命令就能让主机看不到存储卷，一次配置下发就能让整个 fabric 重新构建，业务层的表现是数据库 I/O 挂起、虚拟机批量宕机。而这一切的起点，可能只是那条十年没换过的出厂口令。我见过最夸张的情况是设备管理口直接挂在办公网段上，任何一台能 ping 通它的笔记本都能尝试登录，连扫描都不需要。

很多人有个误区，觉得"我这套 SAN 在内网，外面进不来"。内网不等于安全区，办公终端、测试机、跳板机、厂商远程支持通道，任何一处被拿下，横向到这台交换机只是时间问题。而且这类设备往往缺乏终端防护、不打补丁、日志没人看，一旦被动过，很难第一时间发现。

所以默认口令这件事，正确的定位不是"合规清单上的一项"，而是"整个存储网络信任模型的根"。根一旦是公开的、可猜的、写在所有厂商文档里的，上面挂多少层安全策略都白搭。

1.2 改口令之前必须先摸清的三件事

我踩过的坑里，至少一半来自"上来就改"。改之前，有三件事必须确认清楚，否则很容易把自己或者同事关在门外。

第一件，这台设备到底有几个默认凭据入口。CLI 账号是最容易想到的，但出厂状态下通常还有：Web 管理界面的登录、SNMP 的默认团体字（默认往往是public，只读和读写各一套）、以及某些版本预置的维护类账号。这些入口的凭据经常是分开管理的，改了一个不代表另一个也变了。我就遇到过 admin 口令改得很规范，但 SNMP 读写团体字还是默认值，用一条命令就能把整个配置读出来。

第二件，谁还在用这个账号。改口令之前必须确认没有监控系统、备份脚本、自动化工具在用旧凭据轮询设备。这类程序的特点是失败后不会告警，只是悄悄不干活，等你两周后发现监控数据断档，回溯成本高得离谱。

提示：改密前先翻一遍设备上的登录日志和 SNMP 访问记录，看看有多少来源地址在定期访问管理面，这些地址背后大概率有自动化程序。

第三件，改密过程中业务是否受影响。单纯的账号口令变更本身不中断转发，但为了生效某些配置可能需要禁用交换机，这就完全是另一回事了。所以改密窗口要选在业务低谷，且必须提前确认变更是否牵连 fabric 级操作。

2. 动手前的准备：管理通道、账号模型与基线备份

准备工作做扎实，后面的命令就是走流程。这一节我把连接方式、角色体系和备份动作拆开讲，因为它决定了你在出问题时还有没有回头路。

2.1 三条管理通道，用哪条取决于你手上的牌

光纤交换机一般有三条管理路径：带外管理网口、带内管理地址、以及串口控制台。三者的可用性差别很大，选择顺序也有讲究。

带外管理口是最常规的，独立于业务网络，通过网线直连或接入管理网段。它的优点是稳定、不占业务带宽，缺点是如果管理网段规划混乱，地址可能早就被人忘了。带内管理地址走的是业务端口，安全性差一些，而且网络割接时容易失联。串口控制台是最后的保险，无论网络配置成什么样，插上 console 线就能进，代价是必须到机房现场。

我的习惯是：改密前先用串口确认能进。哪怕平时都用 SSH，也要先验证串口通道畅通。理由很简单——改密过程中最坏的情况是网络配置出问题导致 SSH 失联，这时候串口就是唯一的救命绳。如果串口也进不去，那就只剩恢复出厂或者找厂商支持了，代价完全不同。

连接参数方面，这类设备的串口通常走 9600 波特率、8 数据位、无校验、1 停止位、无流控，终端软件选 VT100 模式。登录后如果看到的是启动日志刷屏，说明设备在重启或者你连上的是启动阶段，等它稳定下来再敲回车。

SSH 登录时注意一点：老版本固件可能只支持较弱的加密算法，新版 SSH 客户端会直接拒绝握手，报"no matching key exchange method"。这不是口令问题，是算法协商问题，需要客户端侧显式开启兼容选项，或者干脆先升级固件。别一开始就往口令上想，白折腾半天。

2.2 账号角色分级：别只知道 admin

这类交换机的账号模型比想象中细。基础版本通常只有admin和user两级，前者全权限，后者只读；而启用高级特性后，会扩展出更多角色，比如负责 fabric 管理的、负责 zone 配置的、负责安全策略的、负责交换机基础运维的。不同角色能碰的命令集完全不同，这是做权限最小化的基础。

看清楚这张表的用意：理想状态下，admin这个账号在日常运维中根本不该被使用。它的正确位置是"封存"，只在紧急情况下启用。日常操作走各自角色的专用账号，谁改了什么，日志上一清二楚。这样做的另一个好处是，当出现异常变更时，你能立刻定位到人，而不是所有人共用一个 admin 互相甩锅。

注意：多人共用 admin 是审计里最容易被判定为高风险的一条。账号共享意味着操作不可追溯，出了事只能查"有人用 admin 登录过"，查不到是谁。

实操上的取舍是：如果设备版本支持多角色，就走"建专用账号 + 封存 admin"的路线；如果只支持两级，那至少要做到"admin 口令足够强 + 只读账号给监控用 + 变更走审批"。别因为版本老就放弃，老设备往往在网络里活得更久，风险敞口反而更大。

2.3 改之前先备份：配置、日志与口头约定

备份这件事，说一百遍都不嫌多。光纤交换机的配置备份通常有两条路：一是把完整配置导出到外部服务器，二是收集一份全量诊断信息，包含配置、日志、端口状态、fabric 成员关系。

导配置的命令大致是这样，执行后会交互式询问传输方式（FTP/SCP/SFTP）和目标地址：

configupload -all

如果只想导 zone 配置，可以加范围参数限定，避免把整份配置带出去。恢复时对应的是configdownload -all，注意这条命令是有破坏性的，会把当前配置整体覆盖，执行前必须确认目标配置版本正确。

全量诊断收集用：

supportsave

这个动作耗时会比较长，尤其是在跑着大量端口的设备上，但它导出的内容最全，出问题的时候就是救命资料。我的习惯是每次重大变更前后各收一份，命名带上日期和变更单号，存到统一的归档目录。

除了技术备份，还有一层"口头约定"：改密前通知到所有可能受影响的团队，包括存储、虚拟化、监控、备份。告知内容至少包括变更时间、影响范围、新凭据的获取方式。别小看这一步，我见过改完密码之后备份任务静默失败了三天，直到有人发现备份窗口没有新数据才追查过来。

3. 实操全流程：从默认口令到一套能交差的口令

准备工作到位，下面进入正题。我把整个过程拆成四刀：改 admin、建专用账号、收窄管理面、多设备批量执行。顺序不能乱，尤其第二刀和第三刀，颠倒过来容易把自己锁在外面。

3.1 第一刀：改掉 admin 的默认口令

登录之后第一件事，先看清当前设备上有哪些账号。这条命令会列出所有本地账号、角色和状态：

userconfig --show -a

输出里要重点看几个字段：账号名、角色、是否启用、口令是否过期。如果看到admin之外还有user、factory之类的预置账号，先记下来，后面统一处理。

改 admin 口令有两种方式。如果你是直接用 admin 登录的，敲：

passwd

按提示输入旧口令、新口令、确认新口令即可。如果是用其他高权限账号登录、要改别人的口令，用：

userconfig --change admin -p

同样会交互式要求输入两遍新口令。这里有个细节：命令行里不要直接把口令作为参数写进去。有些版本支持-p 明文口令的形式，但这样口令会留在命令历史里，等于白改。养成习惯，永远走交互式输入。

新口令怎么定？几条硬性要求：长度至少 12 位，大小写字母、数字、符号四类里至少覆盖三类，不要包含设备型号、厂商名、公司缩写、年份这些可猜元素，也不要用键盘序列或者常见词变形。更专业的做法是用口令管理器生成随机串，人不需要记住，需要时查。

改完之后立刻验证：退出当前会话，重新登录一次。这一步不能省。有些人改完不退出，觉得"命令没报错就是成功了"，结果下次维护时才发现登不上，那时候排查成本高得多。

3.2 第二刀：建专用账号，把 admin 收进保险柜

admin 口令改强只是第一步，接下来要让它"不被日常使用"。做法是建若干个角色受限的专用账号。

新建账号的命令格式大致如下，角色参数按实际需求选：

userconfig --add sanops01 -r admin -p

这里的-r指定角色，-p表示交互式设置初始口令。如果要建只读账号给监控用，把角色换成只读类即可。建完之后，同样要验证登录、验证权限边界——用只读账号尝试执行一条配置命令，确认被拒绝，这才叫真的生效。

账号命名我建议带点信息量，比如"用途+序号"的形式，别用test1、abc这种。命名规范的价值在日志审计时体现得最明显：你一眼就能看出这次操作是监控轮询还是人工变更。

账号建好、验证通过之后，考虑是否禁用或删除多余的预置账号。删除用：

userconfig --delete 账号名

禁用则可以保留账号但关闭其登录能力，具体子参数各版本略有差异，执行前先看帮助输出确认。

注意：删除账号前务必确认它不是某个自动化流程在用的。判断方法很简单，看登录日志里这个账号最近有没有活动记录，有就先去问清楚再动。

这一刀的核心逻辑是"分散风险"。所有人共用一个 admin，等于所有人共享同一把钥匙，任何一个人泄露就是全员泄露；换成每人一个专用账号，泄露面被切割到个人，而且可以通过禁用单个账号快速止损。

3.3 第三刀：把管理面收窄，口令才有意义

口令改得再强，如果管理接口对全网开放，被暴力破解只是时间问题。所以第三刀是收窄访问面，这一步经常被跳过，但它的实际防护价值可能比改口令还高。

最直接的手段是访问控制列表，只允许特定管理网段访问管理服务。命令结构大致是：

ipfilter --create mgmtpolicy -s 10.10.20.0/24 -p ssh -p https ipfilter --activate mgmtpolicy

逻辑是先定义一条策略，声明"允许哪个网段、访问哪些服务"，然后激活它。这里的关键是先确认你自己的来源地址在允许范围内再激活，否则一执行就把自己踢出去了。稳妥的做法是先建一条包含当前管理网段的宽松策略，验证连通后再逐步收紧。

除了地址限制，还要检查几个容易被忽略的入口。SNMP 的团体字如果还是默认值，必须换掉或者干脆升级到带认证加密的版本；Web 管理界面如果没人用，考虑关闭或者同样纳入地址限制；未加密的明文管理协议（比如某些老式管理端口）能关就关，实在要留也必须限制来源。

还有一个常被忽略的点：管理口不要和业务网段混在一起。理想架构是管理网络独立成段，通过跳板机访问，所有管理操作留痕。这在小型环境里可能做不到，但至少要做到管理地址不对外网暴露、不与办公终端同段。

3.4 多交换机环境下的执行顺序与风险控制

真实环境里很少只有一台交换机。一个 fabric 里通常有两台以上，还可能有多套 fabric 并存。批量改密的时候，顺序和节奏就变得重要。

我的建议是逐台执行，改一台验一台，绝对不要图快写个脚本一把梭。原因在于：每台设备的固件版本可能不同，命令支持度有差异；网络路径也可能不同，某台设备从你的位置根本连不上。脚本一跑，报错信息淹没在输出里，你根本不知道哪台成功了哪台失败了。

顺序上，先改非核心设备练手，确认流程顺畅、命令无误，再动核心设备。核心设备的改密窗口单独申请，避开业务高峰，并且提前准备好串口连接作为兜底。

如果 fabric 里配了集中认证，还要额外注意：本地账号和集中认证的关系是"先认证服务器，失败再回落本地"。改本地口令不影响集中认证用户，但如果认证服务器不可达，大家会回落到本地账号，这时候本地账号的口令必须是可用的。所以集中认证环境下，本地账号不能直接删光，至少要保留一个应急账号，口令封存管理。

每改完一台，做三件事：重新登录验证、确认配置未变（对比变更前后的关键配置）、更新凭据台账。台账这件事听起来老土，但它是团队协作的基础。没有台账，三个月后新来的人又得从头摸一遍。

4. 口令策略固化与影响面评估

改一次口令是动作，能不能长期守住是另一回事。这一节讲怎么把这件事制度化，以及改密这件事会波及到哪些地方。

4.1 复杂度、有效期与历史口令

靠人自觉是最不可靠的。较新版本的固件提供了口令策略配置能力，可以把复杂度、有效期、历史口令限制这些规则直接压在设备上，不合规的口令根本设不进去。

配置命令的结构大致如下，具体参数项依版本而定：

passwdcfg --set -minlength 12 -uppercase 1 -lowercase 1 -digit 1 -punct 1 -history 5 -expire 90 -warning 7

这段配置的意图是：最小长度 12 位，四类字符各至少一个，不能重复最近 5 次用过的口令，90 天强制更换，到期前 7 天开始提醒。执行完用passwdcfg --show确认生效。

关于有效期，这里有个实践中的取舍。强制 90 天更换在合规上是常规要求，但过于频繁的更换容易催生" Password1!" → "Password2!" 这种敷衍式变更，反而降低安全性。如果环境允许，我更倾向于"长口令 + 较长有效期 + 强历史限制"的组合，比如 16 位随机口令配 180 天有效期，安全性不输频繁更换。

提示：策略配置完成后，用一条测试账号验证规则是否真的生效——设一个 8 位纯小写口令，看是否被拒绝。规则写了不等于生效，验证过才算。

如果设备版本太老，不支持这些策略，那就要靠外部手段兜底：口令台账定期审查、变更流程强制审批、以及把设备纳入统一的配置核查清单。

4.2 对接集中认证，减少本地账号

设备数量一多，本地账号管理就变成负担。几十台设备几十套口令，靠台账维护迟早出错。这时候应该考虑对接集中认证，把账号体系收到统一目录里。

配置思路是告知设备认证服务器的地址、协议类型、共享密钥和超时时间：

aaaconfig --add 10.10.30.10 -conf radius -p 共享密钥 -t 5 aaaconfig --show

配好之后，用户用自己的目录账号登录，权限按角色映射下发。好处很直接：人员离职只需禁用目录账号，不用逐台设备清理；口令策略统一在目录侧管理，不用关心每台设备的固件版本；登录日志集中，审计方便。

但要注意几个坑。第一，认证服务器不可达时的回落行为必须提前测试，确保本地应急账号可用。第二，角色映射要配准，别出现"某人在目录里是普通用户，登录交换机却拿到全权限"的情况。第三，切换过程中保留原有本地账号一段时间，确认稳定后再清理。

4.3 影响范围：谁会因为这次改密被打断

改密的动作很小，影响面却不小。我通常会在变更前拉一张清单，把可能受影响的方逐个过一遍。

这张表不是摆设，是按"谁依赖这个凭据"的思路列出来的。实际操作中，最容易漏的是自动化脚本和备份任务，因为它们失败时不告警。我一般的做法是改密后 24 小时内主动去查一遍这些系统的执行日志，确认没有认证失败记录。

还有一个隐藏影响：已建立的会话不会立即失效。改完口令后，用旧凭据登录的会话可能还挂着，这给人一种"改了但没生效"的错觉。验证时一定要退出重登，不要在当前会话里判断。

5. 常见问题与排查实录

这部分是我这些年踩坑攒下的，按出现频率排序。

5.1 改完登不上：五个高频原因

第一个原因，大小写或特殊字符输入问题。串口终端和 SSH 客户端对某些符号的处理不一致，尤其是!、$、#这类，在 shell 里可能被解释掉。如果口令里有这些字符，建议换掉，或者确认客户端的输入模式。

第二个原因，认证服务器优先级问题。配了集中认证之后，登录时先问服务器，服务器拒绝就直接失败，不会回落本地。这时候要看服务器的日志，而不是盯着交换机。

第三个原因，账号被锁定。连续多次输错口令会触发锁定策略，锁定期间即使口令正确也登不上。解锁通常用：

userconfig --unlock 账号名

部分版本是userconfig --change 账号名 -u的形式，执行前先看帮助输出。

第四个原因，口令策略拒绝但提示不明显。有些版本在设置口令时，如果不符合复杂度要求，返回的提示很含糊，你可能以为改成功了，其实没生效。改完一定重登验证。

第五个原因，登的是另一台设备。多设备环境下管理地址记混是常事，尤其地址规划不规范的时候。连上去先看一眼设备标识和 fabric 成员关系，确认没走错门。

5.2 口令忘了怎么办：合规恢复路径与代价

忘记口令这件事必须提前想好，真发生了再临时找方案，很容易走弯路甚至做出破坏性操作。

正规的处理路径有三条，按推荐程度排序。第一条，用其他高权限账号登录改回来。这就是为什么前面强调要建专用账号、保留应急账号——只要还有一个可用的高权限账号，问题就不是问题。第二条，走厂商支持通道，提供设备所有权凭证和授权信息，由官方给出恢复流程。第三条，串口恢复流程，不同版本差异极大，有的版本允许在启动阶段进入特殊模式重置，有的版本直接把这条路封了，还有的操作不当会导致配置丢失。

我要特别提醒的是：网上流传的各种"恢复流程"大多针对特定老版本，直接照抄到新版本上，轻则无效，重则把设备搞成砖。真要走这条路，先在备机上验证，或者干脆放弃，用前两条路径。

注意：任何恢复操作前，先确认最近一次配置备份的存在和可用性。恢复流程通常伴随配置重建，没有备份等于从零开始规划 fabric。

5.3 账号锁定与口令过期

这两个问题在规范化管理之后会明显增多，因为它们本来就是策略生效的表现，不是故障。

账号锁定的判断很简单：登录时提示账号被锁或认证失败，但口令确认没输错。这时候查登录日志能看到连续的失败记录，来源可能是某个还在用旧凭据的自动化程序。处理方式是临时解锁 + 找到那个程序更新凭据，否则解锁了还会再被锁。

口令过期的表现是登录后强制要求改密。这时候要注意，部分自动化接口不支持交互式改密，所以给脚本用的账号应该配置成不过期，改由人工定期轮换。这是个常见的设计取舍：安全策略和自动化需求之间要留个例外通道，但例外要登记、要有人负责。

5.4 速查表

最后分享一个小习惯：每次改密完成后，我会在设备上留一条备注式的配置说明（不写口令本身），记录变更日期和变更单号。三个月后再来看，这条备注能省掉大量"这口令到底是谁改的、什么时候改的"的追问。口令本身交给口令管理器，设备上只留线索，这个分工我用了几年，没出过岔子。