Skip to main content

银河麒麟v10高级服务器系统升级 OpenSSH

你的当前版本：

OpenSSH_8.2p1

属于：

OpenSSH <= 9.7p1

因此从版本范围上看，在漏洞影响范围内。

但在麒麟/国产 Linux 中，还需要进一步确认：

是否已经做了 backport 安全修复。

因为很多国产系统不会升级主版本号，只会回补 CVE 修复。

一、先确认是否已修复（非常重要）

执行：

rpm -q --changelog openssh | grep -Ei "CVE|security"

以及：

rpm -q --changelog openssh-clients | tail -50

查看是否出现：

CVE-2024-6387
CVE-2024-6409
scp
command injection

或者类似：

backport security fix

二、确认安装包版本（重点）

执行：

rpm -qa | grep openssh

例如可能看到：

openssh-8.2p1-12.ky10
openssh-clients-8.2p1-12.ky10

关键是：

-12.ky10

这种发行版补丁号。

如果补丁号较老，一般说明未修复。

三、推荐修复方案（麒麟V10）

直接升级 openssh

执行：

yum clean all
yum makecache
yum update openssh openssh-clients openssh-server

或者：

dnf update openssh*

更新后再次查看：

ssh -V

以及：

rpm -qa | grep openssh

四、如果仓库没有更新包

说明：

  • 厂商暂未发布补丁

  • 或未启用安全源

可先执行：

yum repolist

确认：

  • update

  • updates

  • security

仓库是否启用。

五、临时缓解（生产环境建议立即做）

即使没法升级，也建议立即加固。

1. 禁止使用 scp（最有效）

因为漏洞点就在：

scp.c

建议：

  • 全部改为 sftp

  • 或 rsync

例如：

rsync -avz /data user@host:/backup/

2. 限制 SSH 登录 IP

例如：

firewall-cmd --permanent --add-source=你的办公IP
firewall-cmd --reload

3. 禁止 root 登录

编辑：

vi /etc/ssh/sshd_config

修改：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

重启：

systemctl restart sshd

4. 开启 Fail2ban（推荐）

防暴力破解：

yum install fail2ban -y

六、该漏洞的真实风险

这个漏洞：

触发条件

通常需要：

  • 用户主动执行 scp

  • 连接恶意 SSH 服务端

或者：

  • 中间人攻击

因此：

风险级别

场景 风险
内网隔离环境 中
可访问互联网 高
经常使用 scp 拉文件 高
自动化脚本大量 scp 很高

七、生产环境推荐方案（你现在最适合）

建议你按下面顺序处理：

第一优先级

立即：

yum update openssh*

第二优先级

停用：

scp

改：

sftp / rsync

第三优先级

加固 sshd：

禁止root
密钥登录
限制IP

八、建议你再执行两个命令（可直接发我）

请把输出发我，我可以直接帮你判断：

rpm -qa | grep openssh

以及：

rpm -q --changelog openssh-clients | tail -30

我可以进一步帮你确认：

  • 是否真的存在漏洞

  • 是否已被厂商修复

  • 是否只是“版本号误报”

  • 给你最小化修复方案（不影响业务）

从你提供的信息看：

openssh-8.2p1-16.p18.ky10.x86_64

这已经不是原始 upstream 的：

OpenSSH_8.2p1

而是：

麒麟(KY10) 已经深度 backport 的定制版本

并且 changelog 已明确显示：

fix CVE-2023-51385
add backport-CVE-2023-51385-upstream-ban-user-hostnames-with-most-shell-metachar.patch

这非常关键。

一、你当前扫描到的漏洞，大概率属于“版本号误报”

你最开始提到的：

scp.c 命令注入漏洞

实际上对应的是：

CVE-2023-51385

这是 OpenSSH scp/sftp 的：

  • shell 元字符注入

  • 命令注入

  • 参数过滤缺陷

而你的系统已经明确：

fix CVE-2023-51385

说明：

✅ 厂商已经 backport 修复。
✅ 漏洞实际大概率已不存在。
❌ 安全扫描工具只依据 “8.2p1” 版本号误报。

这是国产 Linux 非常常见的情况。

二、为什么会误报

因为漏洞扫描器通常逻辑：

OpenSSH <= 9.7p1 → 判定漏洞

但国产系统：

  • 不升级主版本

  • 只回补 patch

因此：

8.2p1 + backport patch

实际上安全性可能已经等同：

9.x 修复版

三、你当前系统状态判断

根据你提供的信息：

项目状态
OpenSSH 主版本8.2p1
KY10 补丁版本p18
CVE-2023-51385已修复
CVE-2023-38408已修复
CVE-2023-48795已修复
2025 CVE 修复已包含
是否仍存在原始漏洞大概率不存在

四、如何向安全扫描/等保解释（重点）

你现在最需要的是：

“漏洞误报证明”

可以这样写。

漏洞说明模板（可直接用于报告）

漏洞名称：OpenSSH scp 命令注入漏洞

漏洞编号：CVE-2023-51385

漏洞描述：
漏洞扫描工具根据 OpenSSH 主版本号（8.2p1）判定存在漏洞。

实际情况：
当前系统为银河麒麟 V10 定制发行版，OpenSSH 软件包已进行了厂商安全补丁回移（Backport）。

通过 rpm changelog 可确认：

fix CVE-2023-51385
add backport-CVE-2023-51385-upstream-ban-user-hostnames-with-most-shell-metachar.patch

说明厂商已将官方安全修复补丁回移至当前版本。

结论：
该漏洞已被厂商修复，扫描结果属于基于版本号的误报（False Positive），当前系统不存在该漏洞风险。

五、建议你再做一个最终确认（推荐）

执行：

rpm -q --changelog openssh-clients | grep 51385 -A 5

如果能看到：

backport
patch
shell metachar

就可以完全确认。

六、生产环境建议（虽然已修复）

即便已修复，OpenSSH 官方现在也：

不再推荐 scp

建议：

后续逐步替换：

用 rsync

rsync -avz

或 sftp

sftp

因为：

scp 历史设计问题较多

七、你的最终结论（可以直接记）

当前状态：

✅ 漏洞已修复（通过 backport patch）
✅ 安全扫描属于版本号误报
✅ 无需强制升级 OpenSSH 主版本
✅ 可通过 changelog 作为审计证明

八、你现在可以给扫描方的证据

以下命令输出即可作为证明：

rpm -q --changelog openssh

以及：

rpm -q --changelog openssh-clients

关键证据：

fix CVE-2023-51385
backport patch

九、补充一个关键点（非常重要）

你提到的漏洞：

OpenSSH <= 9.7p1

其实和：

CVE-2023-51385

并不完全一致。

因为：

  • 9.7p1 是扫描器泛化规则

  • 真正危险点是：

    • shell metacharacter injection

    • scp 参数过滤

而你已经修补了核心 patch。

所以：

“受影响版本范围” ≠ “实际存在漏洞”

这是 Linux 安全审计里最常见的误区。

Back to top