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_64OpenSSH 命令注入漏洞（CVE-2020-15778）

这已经才是你真正需要处理的漏洞。

前面那个：

CVE-2023-51385

不是原始同一个漏洞。

upstream

一、CVE-2020-15778 是什么

这是 OpenSSH scp 的经典命令注入漏洞。

影响版本：

OpenSSH <= 8.3p1

你的版本：

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
命令注入漏洞

scp 在处理：

目标文件名
远程路径
特殊字符

实际上对应的是时没有严格过滤 shell 元字符。

攻击者可构造：

CVE-2023-51385

` ; & | $( )

这是 OpenSSH scp/sftp 的等特殊字符实现：

  • shell 元字符注入本地命令执行

  • 命令注入

三、关键问题：你现在是否已经修复？

参数过滤缺陷

你当前 changelog

而你的系统已经明确里：

fix没有出现 CVE-2020-15778

这说明：

❌ 目前无法证明已修复。
❌ 大概率确实存在。
✅ 扫描器这次不是误报。

四、为什么之前那个 patch 不算

你已有：

CVE-2023-51385

说明它只是：

后续加强过滤

✅但：

厂商已经
不能完全等价替代 backportCVE-2020-15778 官方修复。
✅
漏洞实际大概率已不存在。
❌ 安全扫描工具只依据 “8.2p1” 版本号误报。

这是国产 Linux 非常常见的情况审计方一般不会认可。

二五、为什么会误报官方修复方式

因为漏洞扫描器通常逻辑OpenSSH 官方在：

OpenSSH <= 9.7p1 → 判定漏洞8.4p1

但中修复了：

CVE-2020-15778

所以理论上：

升级 >= 8.4p1

即可。

六、你当前最现实的修复方案（麒麟环境）

国产系统不能直接编译覆盖 openssh。

否则：

  • 不升级主版本sshd 可能无法启动

  • 只回补PAM patch认证损坏

  • 国密支持丢失

  • 被等保判违规

因此：

推荐方案

方案1（推荐）

联系麒麟源升级：

8.2p1yum +update backport patchopenssh*

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

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 | grep 15778

如果出现：

fix CVE-2020-15778

即可关闭漏洞。

七、如果官方源没有补丁（很常见）

这是国产系统最常见情况。

因为：

8.2p1-16.p18

已经是较新的 KY10 patch level。

但仍未 backport：

15778

八、生产环境临时缓解（审计通常接受）

因为：

漏洞只影响 scp

不影响：

  • ssh

  • sftp

  • rsync

所以及可以：

1. 禁止 scp（最重要）

这是官方推荐缓解。

方法：

限制用户使用：

alias scp='echo "scp disabled due to CVE-2020-15778"; false'

或者：

chmod 750 /usr/bin/scp

更严格：

chmod 700 /usr/bin/scp
chown root:root /usr/bin/scp

2. 全面改用 rsync

例如：

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

3. 或改用 sftp

例如：

sftp user@host

九、审计/漏洞管理如何写（很关键）

很多单位最后采用：

缓解方案 + 风险接受

因为：

  • 厂商没提供补丁

  • 业务不能升级 OpenSSH

这是很常见的。

十、给你一个“整改说明”模板（可直接交付）

漏洞名称：OpenSSH 命令注入漏洞（CVE-2020-15778）

漏洞影响：
OpenSSH scp 模块在处理特殊字符时存在命令注入风险。

当前环境：
系统为银河麒麟 V10，当前 OpenSSH 版本为：
OpenSSH_8.2p1-16.p18.ky10.x86_64

核查情况：
当前厂商补丁中未发现 CVE-2020-15778 修复记录。

整改措施：

  1. 已停止使用 scp 文件传输方式；

  2. 已统一改为 rsync / sftp；

  3. 已限制 scp 二进制执行权限；

  4. 已加强 SSH 登录访问控制；

  5. 持续关注麒麟官方安全补丁更新。

整改结果：
漏洞利用条件已被阻断，风险得到有效缓解。

十一、你现在最推荐的操作

立刻执行（推荐）

禁用 scp

chmod 750 /usr/bin/scp

改用 rsync

yum install rsync -y

查看是否有官方补丁

yum update openssh*

更新后：

rpm -q --changelog openssh-clientsopenssh
|

关键证据：

grep 
fix CVE-2023-51385
backport patch15778

九十二、补充一个关键点不要做的事（非常重要）

你提到的漏洞不要：

源码编译 OpenSSH <=9.x 9.7p1覆盖系统

其实和：

CVE-2023-51385

并不完全一在麒麟上极容易导致。

因为：

  • 9.7p1ssh 是扫描器泛化规则登录失效

  • 真正危险点是：

    PAM

    • shell metacharacter injection崩溃

    • scp国密模块异常

      参数过滤

    • 无法远程连接

而你已经修补了核心 patch。生产环境风险很大。

所以：

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

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

Back to top