紧急安全通告：多款 OpenSSH 与 glibc 高危漏洞曝光，CVE-2023-38408 等须立即修复

发布于：2025-08-30 ⋅ 阅读:(22) ⋅ 点赞:(0)

概述：OpenSSH（OpenBSD Secure Shell）是加拿大OpenBSD计划组的一套用于安全访问远程计算机的连接工具。该工具是SSH协议的开源实现，支持对所有的传输进行加密，可有效阻止窃听、连接劫持以及其他网络级的攻击。 OpenSSH 9.6及之前版本存在安全漏洞，该漏洞源于当使用常见类型的DRAM时，mm_answer_authpassword中已验证的整数值不能抵抗单个比特的翻转，导致攻击者可以绕过身份验证。

目录

一、🚨高危漏洞

二、⚠️ 中危漏洞（建议修复）

三、🔎 低危漏洞（可作为加固措施）

四、✅修复建议

五、🛠修复方案

5.1 在线升级

1. 检查当前版本

2. 在不同系统上的升级方法

🔹 Ubuntu / Debian

🔹 CentOS / RHEL / AlmaLinux

🔹 Amazon Linux / Fedora

3. 升级前的安全措施

4. 升级后验证

5.2 离线升级

1. 上传到服务器

2. 升级 OpenSSL

3. 升级 OpenSSH

4. 备份配置并检查

5. 重启 sshd 并验证

六、 🛡️补充

1. 进入目录并解压

2. 安装依赖

3. 检查依赖是否安装好

七、⚠️异常情况

1.命令：ssh -V

1. 检查新版本是否正确

2. 替换系统默认命令

3. 让 OpenSSH 用新的 OpenSSL

4. 重启 sshd 并验证

2、命令：sshd -t -f /etc/ssh/sshd_config

1.修复权限只允许 root 读写，其他用户不能访问：

2.确认文件归属

3.检查配置文件确认 /etc/ssh/sshd_config 里有类似：

4.重启 sshd

🔄 如果私钥丢失/损坏

一、🚨高危漏洞

  1. CVE-2023-38408（ssh-agent PKCS11 远程代码执行漏洞）

    • 影响版本：OpenSSH 9.3p2 之前

    • 危害：可被远程执行代码

    • 风险分值：9.8

    • 修复：升级至最新版本 OpenSSH

  2. CVE-2024-6387（信号处理竞争条件，远程 root RCE）

    • 影响：glibc 系统上，未经身份验证攻击者可 root 权限执行代码

    • 风险分值：8.1

    • 修复：升级至官方修复版本

  3. CVE-2023-51767（内存比特翻转绕过认证）

    • 危害：攻击者可能绕过密码认证

    • 风险分值：7.0

    • 修复：升级至 OpenSSH 9.7 以上

  4. CVE-2024-6409（信号处理竞争条件漏洞）

    • 危害：可能导致 DoS 或提权

    • 风险分值：7.0

    • 修复：升级至最新版本

二、⚠️ 中危漏洞（建议修复）

  1. CVE-2025-26465（VerifyHostKeyDNS 代码处理不当，可被中间人攻击）

    • 风险分值：6.8

  2. CVE-2023-51385（命令注入漏洞）

    • 风险分值：6.5

  3. CVE-2023-48795（绕过完整性检查）

    • 风险分值：5.9

三、🔎 低危漏洞（可作为加固措施）

  1. CVE-2025-32728（DisableForwarding 指令未完全禁用转发）

    • 风险分值：3.8

  2. CVE-2021-36368（代理转发认证问题）

    • 风险分值：3.7

四、✅修复建议

  1. 立即升级 OpenSSH 至最新稳定版（>= 9.8 或最新 2025 年版本）
    你现在是 OpenSSH 8.8，非常落后，几乎所有漏洞都出在这里。

  2. 如果暂时不能升级，可以考虑临时缓解措施：

    • 禁用 ssh-agent（避免 CVE-2023-38408）

    • 缩短 LoginGraceTime（缓解 CVE-2024-6387）

    • 关闭 VerifyHostKeyDNS 选项（缓解 CVE-2025-26465）

    • 确认 DisableForwarding 配置（缓解 CVE-2025-32728）

  3. 防护措施：

    • 使用防火墙限制 SSH 访问来源（只允许管理端 IP）

    • 启用 Fail2ban 或类似工具防暴力破解

    • 开启 SSH 登录日志监控

五、🛠修复方案

CVE-2023-51767 是硬件层面的 Rowhammer 问题，不属于 OpenSSH 自身逻辑漏洞，所以没有给出补丁，但保持 OpenSSH 升级到 9.7+ 仍然是最佳实践，因为：

  • 新版本修复了其他安全问题（比如内存泄露、DoS、认证绕过等）。

  • 安全团队通常会在新版本中加固潜在风险（比如在敏感变量上增加防护）。

  • 便于日后维护，避免安全扫描时反复报旧版本漏洞。

注意：本文重点讲解离线升级方案

5.1 在线升级

1. 检查当前版本
ssh -V

例如输出：

OpenSSH_9.6p1, OpenSSL 3.0.2 15 Mar 2022
2. 在不同系统上的升级方法
🔹 Ubuntu / Debian

sudo apt update
sudo apt install --only-upgrade openssh-server

如果仓库还没 9.7，可以用 ppa 或者 自行编译：

sudo apt build-dep openssh
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz
tar -xzf openssh-9.7p1.tar.gz
cd openssh-9.7p1
./configure
make
sudo make install
🔹 CentOS / RHEL / AlmaLinux

系统自带版本通常比较旧，可以用 第三方 repo 或 源码编译：


sudo yum update openssh

如果仓库没有 9.7：

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz
tar -xzf openssh-9.7p1.tar.gz
cd openssh-9.7p1
./configure
make
sudo make install
🔹 Amazon Linux / Fedora

Amazon Linux 官方声明“不修复 Rowhammer 类问题”，但你依旧可以升级：


sudo dnf upgrade openssh
3. 升级前的安全措施

  • 保持一个 root 会话不断开（避免 ssh 升级过程中掉线）。

  • 备份配置：

    
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

  • 验证配置文件语法：

    
sshd -t
4. 升级后验证

ssh -V systemctl status sshd

确保版本号 ≥ 9.7，并且 sshd 正常运行。

5.2 离线升级

检查系统现有版本

ssh -V

输出：

OpenSSH_9.1p1, OpenSSL 1.0.2k-fips 26 Jan 2017

服务器连不上 www.openssl.org 或 cdn.openbsd.org，最稳妥的办法就是：

在能上网的本地电脑下载源码包

下载好以后，把 openssh-9.7p1.tar.gz 文件准备好。

1. 上传到服务器

把两个文件传到 /root（假设你已经上传好了，可以直接下一步）。

ls -lh /root/openssh-9.7p1.tar.gz /root/openssl-3.0.17.tar.gz

确认文件存在。

2. 升级 OpenSSL

先升级 OpenSSL（因为 OpenSSH 依赖它）。

cd /root
tar -xzf openssl-3.0.17.tar.gz
cd openssl-3.0.17

# 编译安装
./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl shared zlib
make -j$(nproc)
make install

# 建立软链接，替换旧 openssl
mv /usr/bin/openssl /usr/bin/openssl.bak.$(date +%F-%H%M%S)
ln -s /usr/local/openssl/bin/openssl /usr/bin/openssl

# 更新库文件路径
echo "/usr/local/openssl/lib" > /etc/ld.so.conf.d/openssl.conf
ldconfig -v

# 验证版本
openssl version

预期输出：

OpenSSL 3.0.17 XX XXX 2024

3. 升级 OpenSSH

这里有一个依赖，可以先去第六章节查看。

cd /root
tar -xzf openssh-9.7p1.tar.gz
cd openssh-9.7p1

# 安装依赖
 本文第六章节

# 配置编译，指定新的 OpenSSL
./configure --with-ssl-dir=/usr/local/openssl --with-ssl-engine --sysconfdir=/etc/ssh
make -j$(nproc)
make install

# 备份配置
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M%S)

# 检查配置
./sshd -t -f /etc/ssh/sshd_config

# 重启服务
systemctl restart sshd
ssh -V
4. 备份配置并检查
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M%S)
./sshd -t -f /etc/ssh/sshd_config
5. 重启 sshd 并验证
systemctl restart sshd ssh -V

目标输出：

OpenSSH_9.7p1, OpenSSL 3.0.17 ...

💯 如下图所示说明更新成功

⚠️升级 sshd 时要 保持一个 root 会话不关闭，避免万一 sshd 配置错误把你锁在外面。

六、 🛡️补充

把 openssh-build-deps.tar.gz 和 build-deps.tar.gz 上传到 /root。接下来就是在服务器上解压并安装这些离线依赖包：

1. 进入目录并解压

cd /root

# 解压两个依赖包集合
tar -xzf openssh-build-deps.tar.gz
tar -xzf build-deps.tar.gz

2. 安装依赖

如果里面有很多 .rpm 文件，可以一次性安装：

rpm -ivh *.rpm --force --nodeps

⚠️ 注意：

  • --force 表示覆盖旧版本（如果系统已有）。

  • --nodeps 表示忽略依赖检查，避免因为缺少网络拉不下依赖包而失败。

3. 检查依赖是否安装好

确认 gcc、make、zlib-devel、pam-devel 都能用：

gcc --version
make --version
rpm -qa | grep zlib-devel
rpm -qa | grep pam-devel

七、⚠️异常情况

1.命令：ssh -V

输出：OpenSSH_9.1p1, OpenSSL 1.0.2k-fips 26 Jan 2017这个现象很关键 说明你编译 / 安装的 新 OpenSSH 和 OpenSSL 并没有被系统真正使用，
系统还是在调用 旧的二进制和库：

  • ssh -V 输出 OpenSSH_9.1p1（旧的系统自带版本）
  • OpenSSL 1.0.2k-fips（CentOS/RHEL 7 自带的旧库）

查找新 ssh 在哪里

find /usr/local -name ssh -type f
find /usr/local -name sshd -type f

如果输出如下：

/usr/local/bin/ssh

/usr/local/sbin/sshd

结果说明：

  • 你新编译安装的 OpenSSH 9.7 已经存在：

    • /usr/local/bin/ssh

    • /usr/local/sbin/sshd

    • （还有一份在 /usr/local/openssh/，说明你可能在编译时用了 --prefix=/usr/local/openssh）

  • 系统默认用的还是 /usr/bin/ssh 和 /usr/sbin/sshd（老版本 9.1 + OpenSSL 1.0.2k）。

让系统使用新版本的 ssh/sshd

1. 检查新版本是否正确
/usr/local/bin/ssh -V
/usr/local/sbin/sshd -V

你应该能看到：

OpenSSH_9.7p1, OpenSSL 3.0.17 ...

2. 替换系统默认命令

先备份旧的，再做软链接：

mv /usr/bin/ssh /usr/bin/ssh.bak.$(date +%F-%H%M%S)
ln -s /usr/local/bin/ssh /usr/bin/ssh

mv /usr/sbin/sshd /usr/sbin/sshd.bak.$(date +%F-%H%M%S)
ln -s /usr/local/sbin/sshd /usr/sbin/sshd
3. 让 OpenSSH 用新的 OpenSSL

确认它链接的是 3.0.17：

ldd /usr/local/bin/ssh | grep ssl

如果输出还是 /usr/lib64/libssl.so.10（旧 1.0.2k），说明没走到新库，需要更新库搜索路径：

echo "/usr/local/openssl/lib" > /etc/ld.so.conf.d/openssl.conf
ldconfig -v

再检查：

ldd /usr/local/bin/ssh | grep ssl

应该会看到 /usr/local/openssl/lib/libssl.so.3。

4. 重启 sshd 并验证

systemctl restart sshd ssh -V

预期输出：

OpenSSH_9.7p1, OpenSSL 3.0.17 ...

2、命令：sshd -t -f /etc/ssh/sshd_config

报了/etc/ssh/ssh_host_* 的 权限过宽（0640），导致 sshd 出于安全考虑拒绝使用这些私钥，结果就变成了：sshd: no hostkeys available -- exiting. 也就是说 sshd 根本起不来。

1.修复权限
只允许 root 读写，其他用户不能访问：
chmod 600 /etc/ssh/ssh_host_*_key

（只改私钥，不要动 .pub 公钥文件）

正确权限应该是：

-rw-------  1 root root  /etc/ssh/ssh_host_rsa_key
-rw-------  1 root root  /etc/ssh/ssh_host_ecdsa_key
-rw-------  1 root root  /etc/ssh/ssh_host_ed25519_key
2.确认文件归属
chown root:root /etc/ssh/ssh_host_*_key
3.检查配置文件
确认 /etc/ssh/sshd_config 里有类似：

HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key
4.重启 sshd
systemctl restart sshd
systemctl status sshd
🔄 如果私钥丢失/损坏

如果 /etc/ssh/ssh_host_* 文件不存在或不可用，可以重新生成：

ssh-keygen -A

它会自动在 /etc/ssh/ 下生成新的 ssh_host_* 密钥对。

建议先跑：

ls -l /etc/ssh/ssh_host_*_key

最后在看一下是否修复

systemctl status sshd

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章

最新发布