交换机ssh进程占用cpu问题

怎么确认是ssh占用的？ 

H3C V7 交换机关闭 SSH 服务，但 sshd 进程依旧 40% CPU 占用
现象：执行undo ssh server enable关闭 SSH 服务，display ssh server status显示 SSH 服务已Disabled，但sshd/stelnetd进程 CPU 持续 40%，属于进程僵尸残留、半连接攻击、版本 bug，关闭配置无法立刻杀死后台进程。
步骤 1：确认现状，收集关键信息
bash
#1、确认SSH服务器配置确实关闭
display ssh server status
display current‑configuration | include ssh server enable

#2、确认是哪个进程高CPU（sshd / ssh）
display process cpu | exclude 0.0%

#3、查看是否残留TCP半连接、异常22端口会话（攻击扫描）
display tcp status | include 22
display ssh user‑information

#4、看CPU历史
display cpu‑usage history
重点：即使 ssh server 关闭，外网持续发来大量 22 端口 TCP 握手报文，报文上送 CPU，会造成 sshd 进程僵死高 CPU，属于常见攻击场景。
步骤 2：清理残留 SSH 会话，尝试释放进程
强制释放全部残留 SSH 会话
bash
free ssh all
重新开关 SSH 服务，尝试触发进程重启
bash
system‑view
ssh server enable
undo ssh server enable
save force
部分版本关闭配置后，僵尸子进程不会自动销毁；重新开关一次服务，可触发进程回收。
步骤 3：配置 CPU 防攻击（如果外网有大量 22 端口扫描，优先配置）
防止大量 TCP SYN 报文持续上送 CPU 打满 sshd 进程，即使关闭 SSH，报文依然会上送 CPU。
bash
system‑view
cpu‑defend policy SSH‑PROTECT
#限制stelnet/ssh报文上送CPU速率
car stelnet cir 64 cbs 4000
#开启应用攻击防护，处理大量半连接
cpu‑defend application‑attack‑protection enable
#把策略应用到CPU
cpu‑defend apply policy SSH‑PROTECT
quit
配置完观察 CPU，如果 CPU 下降，说明是外部扫描攻击导致。
步骤 4：临时规避方案（业务允许重启）
如果上面操作后 CPU 依旧 40%，属于进程僵死（Comware V7 版本 bug），配置关闭无法回收僵尸进程。
IRF 堆叠环境，优先主设备重启；单机直接重启整机。
重启后 sshd 进程彻底销毁，CPU 恢复正常。
⚠️如果业务不允许整机重启，临时方案：不要关闭 ssh server，使用 ACL 拒绝所有源访问 22 端口，比单纯关闭 ssh 服务更有效。
bash
acl number 3000
rule deny tcp any any eq 22
system‑view
ssh server enable
ssh server acl 3000
SSH 服务配置上保持 enable，但 ACL 直接拦截所有 22 端口报文，不会有报文上送 CPU，sshd 进程空闲，CPU 不会高占用。
步骤 5：根本修复（版本 BUG）
很多中早期 V7 版本存在 sshd 僵尸进程 bug：undo ssh server enable后后台进程不退出，持续占用 CPU。
查看版本 display version，建议升级到对应系列最新 ReleaseP 版本，修复该缺陷。
排错区分点（很容易误判）
❗不要误以为关闭ssh server enable，22 端口报文就不会上送 CPU：关闭服务只是不响应连接，收到的 TCP 报文仍然会上送到 CPU 处理，大量扫描报文会造成进程卡死高 CPU，必须 ACL+cpu‑defend 拦截报文。
IRF 堆叠，要确认所有成员都已经 undo ssh server enable，备机残留进程会同步。
收集信息给 400 定位（如果重启后复现）
display process cpu输出
display tcp status
display version
display cpu‑usage history
快速故障总结
先free ssh all释放会话，重新开关 ssh 服务；
配置cpu‑defend限速，抵御外部 22 端口扫描报文；
无效就整机重启临时恢复；
长期解决：要么 ACL 拦截 22 端口，要么升级设备固件版本修复进程 bug。