MSR3620-G-X3 通过SSH登录敲命令卡住，没输出

99% 并非漏洞攻击导致，属于设备资源耗尽、日志缓存阻塞、SSH 会话机制异常三类运维故障；MSR3620-G-X3 不存在公开可造成「执行 display logbuffer 卡死无输出」的远程漏洞。
只有设备固件存在老旧 SSH 高危漏洞、同时内网存在攻击者持续恶意探测时，才会顺带加剧 SSH 卡顿，但不会精准触发仅display logbuffer卡死的现象。
一、为什么执行 display logbuffer 单独卡住（核心 4 个真实诱因，按概率排序）
诱因 1：设备 CPU 满载、日志缓冲区溢出阻塞命令（最常见）
display logbuffer 需要完整读取设备内存里的系统日志缓存，如果日志疯狂刷屏（环路、端口频繁 UP/DOWN、攻击日志、蠕虫扫描），日志缓冲区写满占用系统内核资源，CPU 被日志进程占满：
CPU 长期＞85%，设备没有空闲进程来响应 SSH 下发的查询指令；
日志缓存溢出锁死，读取日志命令直接阻塞超时，表现为敲命令空白、几秒后会话刷新需要重新输入。
排查命令（优先 Console 口登录执行，Console 不受 SSH 阻塞影响）：
bash
display cpu-usage
display cpu-usage task # 查看哪个进程占满CPU，重点看LOG、ARP、STP进程
display logbuffer summary
典型特征：LOG进程占用 CPU 70% 以上、日志条数几十万条持续暴涨。
诱因 2：logbuffer 日志缓存损坏 / 塞满脏日志，读取进程死锁
设备异常断电、反复重启会造成内存日志缓存结构损坏：
执行display logbuffer时系统尝试解析损坏日志片段，进程卡死；
SSH 会话等待超时断开，你看到「卡住无输出，重新输入命令」。
修复方式（Console 操作）：
bash
reset logbuffer # 清空损坏的内存日志缓存
诱因 3：SSH 会话资源耗尽、VTY 会话抢占冲突
VTY 虚拟终端数量耗尽（大量 SSH 会话残留僵尸连接），新 SSH 拿到的 VTY 资源优先级极低，执行复杂读取命令直接阻塞；
SSH 服务开启了 GSSAPI 反向解析，每执行一条命令设备反向解析客户端 IP DNS，内网无 DNS 时反复解析超时，造成命令卡住。
查看 VTY 占用：
bash
display users
清理闲置会话：free user 会话编号。
诱因 4：设备 Flash 存储空间 100% 占满
日志自动往 Flash 持久写入、debug 开关误开启，磁盘写满后：
系统所有 IO 类命令（查看日志、保存配置）全部阻塞；
SSH 执行读取类命令无响应，仅简单命令（display clock）能正常运行。
校验磁盘：
bash
display device storage
使用率 100% 则删除 Flash 内无用日志、旧版本固件释放空间。
二、会不会是漏洞利用导致？详细说明
1、不存在能精准卡死 display logbuffer 的漏洞
目前公开的 MSR 全系列漏洞（包括老旧 CMW520/CMW710 版本漏洞）分为三类：
1）SSH 弱口令爆破、会话枚举；2）Web 界面命令注入；3）越权读取配置；
没有任何 CVE 漏洞可以定向让display logbuffer单独卡死。
攻击者就算利用 SSH 漏洞入侵，目的是窃取配置、提权，不会刻意阻塞日志查询命令。
2、老旧固件确实存在 SSH 漏洞，会「加重 SSH 整体卡顿」
如果你的 MSR 固件版本老旧（CMW710 E5205 及更早版本），存在：
SSH 会话耗尽漏洞：恶意批量新建 SSH 僵尸连接占满 VTY，导致正常 SSH 执行命令缓慢、偶发卡死；
SSH 密钥协商熵池阻塞漏洞：大量扫描连接耗尽随机数池，SSH 交互卡顿。
区分特征：
漏洞攻击：所有 SSH 命令（display clock、display version）全部缓慢卡顿；
日志阻塞故障：只有display logbuffer、display diag这类读取日志命令卡死，简单命令秒回。
结合你的现象「仅查看日志卡住」，可以排除漏洞攻击为主因。
3、如何确认是否遭受恶意扫描 / 入侵
Console 登录执行两条命令核验：
bash
display logbuffer | include SSH|stelnet # 查看是否大量SSH暴力破解、异常登录日志
display connection-control statistics # 查看是否存在海量异常TCP连接
出现几十上百条 SSH 失败登录记录，说明存在外网 / 内网爆破扫描，扫描会挤占设备性能加剧卡顿，但并非卡死日志命令的根源。
三、分步修复方案（先止血，再根治）
阶段 1：Console 接入紧急恢复（避免 SSH 彻底卡死无法运维）
Console 口登录，清空卡死的日志缓存
plaintext
system-view
reset logbuffer
undo info-center enable # 临时关闭日志上报降压，排查完毕再开启
释放僵尸 VTY 会话
plaintext
display users
free user X
清理满负荷 Flash 磁盘
plaintext
dir flash:
delete /unreserved flash:/xxx.log 删除老旧日志文件
阶段 2：优化 SSH 配置，杜绝解析超时卡顿
plaintext
system-view
# 关闭SSH冗余GSSAPI反向解析，避免每条命令做DNS解析阻塞
ssh server gssapi disable
# 合理VTY数量，防止会话占满
user-interface vty 0 15
authentication-mode scheme
idle-timeout 3 0 # 闲置3分钟自动断开僵尸会话
阶段 3：根治日志刷屏导致 CPU 跑高
排查环路、端口震荡：
plaintext
display link-flap
display stp brief
发现环路立刻部署环路检测：loopback-detection enable；
2. 调低日志输出级别，只记录告警级别日志，减少日志爆发：
plaintext
info-center source default logbuffer level warning
阶段 4：安全加固（规避 SSH 漏洞被利用）
将 MSR 固件升级至 CMW710-E5208P03 稳定版本，修复全部 SSH 历史漏洞；
管理 ACL 限制 SSH 来源，仅运维内网 IP 允许登录 SSH：
plaintext
acl number 3000
permit source 运维网段 0
rule deny
ssh server acl 3000
四、快速区分故障 / 攻击对照表
表格
现象 故障（日志阻塞 / CPU 满载） 漏洞恶意攻击
仅 display logbuffer 卡死，clock/version 正常 ✅ 属于日志缓存 / 资源故障 ❌
所有 SSH 命令全部缓慢、时常断开 可能 CPU 过高，也可能 SSH 攻击 存在扫描 / 漏洞探测
日志里大量 SSH 失败登录记录 单纯爆破扫描，非漏洞入侵 攻击者正在尝试爆破
设备莫名新增管理员账号、配置被篡改 ✅ 已经被入侵
五、总结
本次故障核心是日志缓存爆满 / 损坏、CPU 被日志进程打满，读取日志命令阻塞超时，和漏洞无关；
仅当全量 SSH 命令都卡顿、大量 SSH 爆破日志时，才需要考虑老旧 SSH 漏洞被扫描利用；
处理顺序：Console 清空日志缓存释放 CPU → 关闭 SSH 反向解析 → 排查环路 / 端口震荡避免日志刷屏 → 升级固件封堵 SSH 漏洞。

你可以按照下面的步骤，通过Console口（它能避开SSH阻塞的影响）登录设备进行排查。

🔍 第一步：定位故障根源

在Console口下，执行以下命令来检查设备状态：

1. 检查CPU使用率：

   bash

   display cpu-usage display cpu-usage task

   • 关键点：重点关注LOG、ARP、STP等进程。如果CPU长期高于85%，或LOG进程占用超过70%，很可能是日志刷屏导致CPU满载。

2. 检查日志缓存状态：

   bash

   display logbuffer summary

   • 关键点：查看日志缓冲区是否已被大量信息填满。

3. 检查VTY（虚拟终端）会话占用：

   bash

   display users

   • 关键点：检查是否有大量僵死的SSH会话（处于Idle或Estab状态但无实际操作）占用了VTY资源。

4. 检查存储空间：

   bash

   display device storage

   • 关键点：检查Flash存储空间使用率是否已满（100%）。磁盘写满会导致所有IO类命令（如查看日志、保存配置）阻塞。

🛠️ 第二步：根据原因进行修复

情况A：日志刷屏导致CPU过载

如果确认是日志过多导致CPU满载，可以尝试清空日志缓存来快速恢复。

1. 清空日志缓存（风险较低，可在业务高峰期操作）：

   bash

   reset logbuffer

   这将清空内存中的日志缓存。如果问题是由日志刷屏引起，清空后CPU使用率应会下降，SSH命令响应也会恢复正常。

2. 排查日志源：
   清空后，使用 display logbuffer 再次查看新产生的日志，找出是哪个模块在不断刷屏（如端口频繁UP/DOWN、环路告警等），并从根源上解决。

情况B：VTY会话资源耗尽

如果display users显示有大量僵死会话，可以手动清理。

（<会话编号>替换为要清理的会话ID）

情况C：Flash存储空间已满

如果display device storage显示使用率为100%，需要清理空间。

1. 通过dir命令查看Flash中的文件。

2. 删除无用的日志文件、旧版本固件等来释放空间。

🚀 第三步：预防措施与长期建议

1. 升级软件版本：如果当前固件版本较旧，建议升级到最新稳定版。新版本通常会修复已知的性能问题和SSH服务缺陷。

2. 优化SSH服务配置：

   • 关闭DNS反向解析：如果内网无DNS，可关闭此功能，避免每次执行命令时的解析超时。

   • 设置ACL访问控制：限制仅允许特定的管理IP通过SSH登录，提高安全性。

3. 配置日志存储策略：考虑将日志输出到远程日志服务器，避免本地日志缓存溢出