OpenSSH 8.7升级与安全加固实战：禁用老旧算法与配置优化

1. 项目概述：为什么必须升级OpenSSH并禁用老旧算法？

最近在给几台线上服务器做安全加固，发现一个普遍但容易被忽视的问题：很多CentOS 7、RHEL 7甚至一些老版本的Ubuntu服务器，默认安装的OpenSSH版本还停留在7.4、7.9这些“古董”版本。这些版本默认支持的加密算法、密钥交换协议和消息认证码（MAC）中，包含了不少如今已被证实存在安全风险或强度不足的老旧算法，比如SSH-1协议、CBC模式的加密算法、或者像hmac-md5这样的弱MAC。更棘手的是，一些老旧的客户端（或者某些嵌入式设备、自动化脚本）可能还在使用这些不安全的算法进行连接，而服务器为了兼容性，往往默认开启了支持，这就给整个系统留下了安全隐患。

我这次实战的目标很明确：将服务器上的OpenSSH从7.4版本升级到目前稳定且功能丰富的8.7（或更高）版本。升级本身不是目的，核心是通过升级获得对新安全特性的支持，并借此机会，一劳永逸地在服务端禁用所有不安全的加密套件。这就像给家里的老锁全部换成最新的智能锁，不仅锁芯更安全，还把那些容易被撬的旧锁眼彻底焊死。整个过程需要在保证现有业务连接不中断（或影响最小化）的前提下进行，每一步操作都要有回滚方案，毕竟SSH是运维的生命线，搞砸了连服务器都进不去就尴尬了。

2. 升级前准备：风险评估与完整备份策略

在动任何生产环境软件之前，尤其是像OpenSSH这种核心服务，准备工作做得越充分，翻车的概率就越低。这一步的核心是“知己知彼”，并准备好“后悔药”。

2.1 环境探查与兼容性评估

首先，你需要清楚地知道当前系统的状态。登录目标服务器，执行以下命令：

# 查看当前OpenSSH服务端版本 sshd -V 2>&1 | head -n 1 # 查看当前sshd进程使用的配置文件路径 ps aux | grep sshd | grep -v grep | head -1 # 查看当前sshd_config中的关键算法配置（提前了解现状） grep -E “^(Ciphers|KexAlgorithms|MACs)” /etc/ssh/sshd_config || echo “未显式配置，使用默认值”

记录下当前的版本号（比如OpenSSH_7.4p1）和配置文件路径（通常是/etc/ssh/sshd_config）。接下来，评估客户端兼容性。你需要统计有哪些客户端、自动化工具（如Ansible、Jenkins Agent）、跳板机或第三方服务会连接到这台服务器。一个实用的方法是分析当前的认证日志：

# 查看最近成功连接的客户端版本信息（需要sudo权限） sudo grep “Accepted publickey” /var/log/secure | tail -20 | awk ‘{print $NF}’ | sort | uniq -c

这个命令能帮你看到最近有哪些客户端IP和SSH版本连接成功。特别留意那些版本号很老的客户端（比如OpenSSH_5.3）。对于这些老旧客户端，你需要提前与相关方沟通，推动其升级，或者为它们制定特殊的、临时的连接策略（这会在后面的配置中讲到）。

2.2 配置文件与二进制文件的完整备份

这是你的“救命稻草”。不要仅仅复制配置文件，要把整个相关的目录和当前的二进制文件都备份好。

# 创建备份目录，以日期时间命名，清晰明了 BACKUP_DIR=“/root/ssh_backup_$(date +%Y%m%d_%H%M%S)” mkdir -p $BACKUP_DIR # 1. 备份当前sshd主配置文件 cp -a /etc/ssh/sshd_config $BACKUP_DIR/ # 2. 备份整个/etc/ssh目录（包含主机密钥等） cp -a /etc/ssh $BACKUP_DIR/etc_ssh_backup/ # 3. 备份当前openssh相关的所有rpm包（针对RHEL/CentOS） rpm -qa | grep openssh > $BACKUP_DIR/openssh_packages.list # 如果可以，将列出的包下载到本地备份 yumdownloader —destdir=$BACKUP_DIR/rpms $(rpm -qa | grep openssh) 2>/dev/null || true # 4. 备份当前的sshd二进制文件（关键！） cp -a $(which sshd) $BACKUP_DIR/sshd.bin.old # 5. 备份当前ssh客户端二进制文件（可选，但建议） cp -a $(which ssh) $BACKUP_DIR/ssh.bin.old

注意：cp -a参数保留了文件的所有属性（权限、所有权、时间戳），这在恢复时至关重要。将$BACKUP_DIR打包压缩后，最好能下载到本地管理机一份，防止服务器磁盘故障导致备份也丢失。

2.3 准备回滚方案与应急连接通道

在升级和修改配置期间，最坏的情况是新的sshd服务无法启动，或者启动后所有客户端都无法连接。你必须为自己留一条“后路”。

方案一：保持现有sshd进程运行，在新端口启动测试实例。这是最安全的方法。我们不直接替换正在运行的sshd服务，而是编译或安装新版本后，让它运行在另一个端口（比如2222）上。这样，你可以用新客户端连接到新端口进行充分测试，而原有的业务连接完全不受影响。

方案二：准备一个独立的、已知可用的救援连接方式。这可以是：

1. 服务器控制台（iDRAC、iLO、KVM over IP）。确保你知道如何登录并使用它。
2. 在服务器上预先安装一个非常轻量级的、独立于OpenSSH的备用SSH服务，比如dropbear。在升级前安装并配置好，但先不启用。万一主SSH挂了，可以紧急启动dropbear救急。
3. （对于云服务器）确保安全组/防火墙规则允许你从某个管理IP通过“救援模式”或“串行控制台”连接。

我个人的习惯是采用“方案一”作为主要测试手段，同时确保“方案二”中的控制台可用，做到双保险。

3. 实战升级：从源码编译到RPM包管理

升级OpenSSH主要有两种主流方式：从源码编译安装和使用预编译的RPM包升级。两种方式各有优劣，我会详细拆解。

3.1 方案选择：源码编译 vs RPM包升级

• 源码编译：
  • 优点：灵活性最高，可以指定安装路径（/usr/local）、编译参数，适用于任何Linux发行版，尤其适合那些官方仓库版本陈旧的环境。
  • 缺点：步骤稍多，需要手动解决依赖（如OpenSSL、zlib的开发包），后续系统级更新（如yum update）不会管理你自己编译的软件，需要自己维护。
• RPM包升级：
  • 优点：简单快捷，使用yum或rpm命令即可完成，完美集成到系统包管理中，便于后续统一更新和回滚。
  • 缺点：依赖特定发行版的仓库或第三方EPEL仓库，版本可能不是最新的。直接升级系统自带的核心包有一定风险，可能被其他包依赖。

对于CentOS 7/RHEL 7，其官方仓库的OpenSSH版本锁定在7.4，要升级到8.x，通常需要从第三方仓库（如EPEL、IUS）获取或手动下载高版本RPM包。对于Ubuntu/Debian，可以通过添加backports源或直接下载deb包。

我的建议是：如果服务器数量少，且你对编译过程熟悉，追求版本的绝对控制和最小化变更，可以用源码编译。如果服务器数量多，需要标准化部署和后续便捷管理，则寻找或自己打一个可靠的RPM包是更优解。下面我将分别展示两种方式的核心步骤。

3.2 方式一：通过源码编译安装OpenSSH 8.7

假设我们选择安装在/usr/local目录下，与系统自带的/usr/bin/ssh隔离。

# 1. 安装编译依赖 yum install -y gcc make openssl-devel pam-devel zlib-devel wget # 2. 下载OpenSSH 8.7源码包（请替换为最新稳定版链接） cd /usr/local/src wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.7p1.tar.gz tar -zxvf openssh-8.7p1.tar.gz cd openssh-8.7p1 # 3. 配置编译选项 # —prefix 指定安装目录 # —with-ssl-dir 指定OpenSSL库路径（重要！） # —with-pam 启用PAM支持 # —with-zlib 启用压缩支持 ./configure —prefix=/usr/local/openssh-8.7 —with-ssl-dir=/usr —with-pam —with-zlib # 4. 编译并安装 make # 在安装前，建议先备份旧版的ssh、sshd等命令（如果你打算替换系统默认的） sudo make install # 5. 创建软链接，将新版本命令加入系统PATH（谨慎操作！） # 这一步会让系统默认使用新版本的ssh/sshd。建议先不执行，而是通过绝对路径测试。 # ln -sf /usr/local/openssh-8.7/bin/ssh /usr/local/bin/ssh # ln -sf /usr/local/openssh-8.7/sbin/sshd /usr/local/sbin/sshd # 6. 复制默认配置文件（如果目标目录没有） cp /usr/local/openssh-8.7/etc/sshd_config /usr/local/openssh-8.7/etc/sshd_config.default

编译完成后，新的sshd二进制文件位于/usr/local/openssh-8.7/sbin/sshd。你可以用它来启动一个测试实例。

3.3 方式二：通过RPM包升级（以CentOS 7为例）

对于生产环境，我更倾向于使用可靠的RPM包。我们可以从较新的仓库获取，或者自己下载RPM包手动安装。

方法A：从EPEL/IUS仓库安装（如果仓库版本足够新）

# 启用EPEL仓库 yum install -y epel-release # 查看EPEL仓库提供的openssh版本 yum —disablerepo=“*” —enablerepo=“epel” list available openssh-server # 如果版本符合要求，直接升级 yum —enablerepo=epel update openssh-server openssh-clients

方法B：手动下载并安装RPM包有时仓库版本不够新，我们需要手动找包。可以从Fedora的Koji构建系统、或第三方如openssh.com的RPM仓库下载对应CentOS 7的包。

# 示例：下载openssh-8.7p1的RPM包（需要提前找到正确的下载链接） wget https://some-mirror/openssh-8.7p1-1.el7.x86_64.rpm wget https://some-mirror/openssh-clients-8.7p1-1.el7.x86_64.rpm wget https://some-mirror/openssh-server-8.7p1-1.el7.x86_64.rpm # 安装前，先检查依赖 rpm -Uvh —test openssh-*.rpm # 如果依赖检查通过，进行安装（U代表升级） rpm -Uvh openssh-*.rpm

重要提示：使用rpm -Uvh升级时，旧的配置文件会被保存为sshd_config.rpmsave。你需要仔细比较新旧配置文件的差异，并将必要的自定义配置合并到新文件中。切勿直接覆盖新配置文件！

3.4 启动测试实例与功能验证

无论采用哪种方式安装，都不要急着替换系统服务。先在新端口上启动一个测试实例。

# 假设新sshd路径是 /usr/local/openssh-8.7/sbin/sshd # 或通过RPM安装后，直接使用 /usr/sbin/sshd (已是新版本) # 1. 复制一份配置文件用于测试 cp /etc/ssh/sshd_config /tmp/sshd_config_test # 2. 修改测试配置文件的关键参数 sed -i ‘s/#Port 22/Port 2222/’ /tmp/sshd_config_test # 更改端口 sed -i ‘s/#ListenAddress 0.0.0.0/ListenAddress 127.0.0.1/’ /tmp/sshd_config_test # 仅监听本地，避免外部误连 # 暂时不要禁用算法，先确保能连接 # 3. 使用新版本的sshd，加载测试配置启动 /usr/local/openssh-8.7/sbin/sshd -f /tmp/sshd_config_test -d # 或者如果是RPM升级后的： /usr/sbin/sshd -f /tmp/sshd_config_test -d # 使用 -d 参数在前台调试模式运行，观察输出。如果没有报错，按Ctrl+C停止，然后用 -D 参数后台运行。 /usr/sbin/sshd -f /tmp/sshd_config_test -D &

现在，打开另一个终端，尝试用新版本的ssh客户端连接测试端口：

ssh -p 2222 -v localhost

在-v（详细）输出中，你应该能看到连接过程，并最终成功登录。同时，观察服务器端测试sshd的日志输出，确认没有错误。这个步骤验证了新版本二进制文件与当前系统环境（PAM、SELinux等）的兼容性。

4. 核心安全加固：精准禁用老旧加密算法

升级成功只是第一步，真正的安全加固在于配置。OpenSSH 8.x 版本提供了更精细的算法控制能力。我们的目标是：在sshd_config中，明确指定一个仅包含强算法、排除了所有已知弱算法的白名单。

4.1 理解算法配置项：Ciphers, KexAlgorithms, MACs

在sshd_config中，有三个核心指令控制算法协商：

1. Ciphers：指定允许的对称加密算法，用于加密会话数据。需要禁用所有CBC模式算法和弱算法。
2. KexAlgorithms：指定密钥交换算法。需要禁用不安全的DH组和SHA-1哈希的算法。
3. MACs：指定消息认证码算法，用于数据完整性校验。需要禁用MD5和SHA-1等弱哈希算法。

首先，查看新版本OpenSSH支持的所有算法，以便我们从中挑选：

# 查看sshd支持的所有算法列表 sshd -G | grep -E “ciphers|kexalgorithms|macs” # 或者更精确地，启动一个临时sshd输出所有配置默认值（包括算法） /usr/sbin/sshd -T | grep -E “^ciphers|^kexalgorithms|^macs”

4.2 构建安全的算法白名单配置

以下是我在多次加固后总结出的、一个相对激进但兼容性尚可的白名单配置。它禁用了所有已知的弱算法和传统算法。

# 编辑 /etc/ssh/sshd_config，在文件末尾或合适位置添加： # 1. 对称加密算法：仅保留CTR模式或GCM模式的强算法 # 禁用所有cbc*算法，它们容易受到选择明文攻击（CPAs）。 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr # 2. 密钥交换算法：使用现代、前向安全的算法 # 禁用所有使用sha1哈希的diffie-hellman-group-exchange-sha1*和diffie-hellman-group1-sha1, diffie-hellman-group14-sha1。 # curve25519-sha256 是目前首选。 KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 # 3. 消息认证码算法：仅使用基于SHA-2或ETM（Encrypt-then-MAC）的强算法 # 禁用所有hmac-md5*, hmac-sha1*, 以及任何不带-etm后缀的算法（易受长度扩展攻击）。 MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

配置逐行解读与避坑指南：

• Ciphers顺序：客户端和服务器会按照配置的顺序协商算法。我把最安全、性能也不错的chacha20-poly1305和aes-gcm放在前面。aes-ctr作为广泛兼容的备选。
• 关于diffie-hellman-group-exchange-sha256：这个算法允许动态协商DH组大小，比固定组（如group14）更灵活安全，但需要服务器端额外生成DH参数，可能会略微增加首次连接的开销。如果担心性能，可以保留diffie-hellman-group16-sha512（如果支持）或diffie-hellman-group18-sha512。
• -etm后缀的重要性：Encrypt-then-MAC模式是先加密再计算MAC，比默认的MAC-then-Encrypt更安全，能有效防御某些特定的攻击。OpenSSH 6.2及以上版本都支持ETM模式。务必确保你的MACs列表里只包含带-etm后缀的算法，或者像umac-128@openssh.com这种本身设计就安全的算法。
• 兼容性测试：配置完成后，务必用sshd -t测试配置文件语法，然后用一个新版本客户端（如OpenSSH 7.2+）和一个刻意保留的旧版本客户端（如OpenSSH 5.3）分别连接测试。旧客户端应该因“no matching cipher/kex/mac”而连接失败，这正好验证了我们的禁用策略生效了。

4.3 处理老旧客户端的过渡方案

如果确有无法立即升级的老旧客户端（比如某个嵌入式设备），全部禁用会导致业务中断。有两种过渡方案：

方案一：为特定来源IP开放宽松算法（不推荐长期使用）使用Match块，对来自特定IP的老旧客户端应用另一套较宽松的算法配置。

# 在sshd_config文件末尾添加 Match Address 192.168.1.100 # 替换为老旧客户端的IP Ciphers aes128-cbc,aes256-cbc,3des-cbc # 仅允许必要的弱算法 KexAlgorithms diffie-hellman-group14-sha1 MACs hmac-sha1

方案二（推荐）：使用“跳板机”或“SSH代理”在一台独立的、安全策略稍松的服务器（跳板机）上，允许老旧客户端连接。然后从这台跳板机，使用新版本、强算法的SSH连接到目标服务器。这样，老旧客户端到跳板机的连接被隔离在内部网络，而跳板机到目标服务器的连接则是强加密的。这为升级老旧客户端赢得了时间。

5. 完整部署流程与最终验证

经过测试后，就可以将新配置应用到生产环境的SSH服务了。

5.1 正式替换与服务重启

1. 合并配置：将测试成功的算法白名单配置，合并到系统的/etc/ssh/sshd_config文件中。确保你只修改了Ciphers,KexAlgorithms,MACs这三行，或者添加了Match块，没有误删其他重要配置（如PermitRootLogin,PasswordAuthentication等）。
2. 语法检查：执行sshd -t。如果输出“configuration OK”，则语法无误。
3. 备份运行配置：cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak_before_hardening。
4. 重启服务：

   # 对于systemd系统 systemctl restart sshd # 对于SysVinit系统 service sshd restart

5. 验证服务状态：

   systemctl status sshd # 或查看日志 tail -f /var/log/secure

   确保服务是active (running)状态，并且日志中没有error级别的报错。

5.2 全面的连接与安全扫描验证

服务重启后，不能只简单连接一下了事，需要进行多维度验证。

验证一：新版本客户端连接测试从一台版本较新的管理机（OpenSSH 7.2+）连接，使用-v参数查看协商出的具体算法：

ssh -v user@your_server 2>&1 | grep -E “cipher:|kex:|mac”

输出应该显示使用的是我们白名单里的强算法，例如cipher: chacha20-poly1305@openssh.com。

验证二：老旧客户端连接失败测试故意用一个很老的客户端（或者用ssh -o选项模拟）连接，预期应该收到类似no matching cipher/kex/mac found的错误。这证明弱算法已被成功禁用。

验证三：使用专业工具扫描使用nmap或ssh-audit等工具对服务器的SSH服务进行安全扫描，这是最客观的验证。

# 使用nmap的ssh2-enum-algos脚本扫描支持的算法 nmap —script ssh2-enum-algos -p 22 your_server # 使用ssh-audit进行深度审计（推荐） # 可以从GitHub下载：https://github.com/jtesta/ssh-audit python3 ssh-audit.py your_server

ssh-audit会给出一个非常详细的报告，列出所有支持的算法，并对不安全的算法给出警告（FAIL）。我们的目标是让报告中所有关于cbc,sha1,md5,weak的警告都消失，或者仅剩下在Match块中为特定IP保留的（这部分会被识别，但通常会有说明）。

验证四：关键业务自动化脚本测试通知所有相关方，并安排一个维护窗口，让使用此服务器的CI/CD流水线（Jenkins、GitLab Runner）、监控代理、备份脚本等进行实际的连接测试，确保功能正常。

5.3 常见问题排查与回滚操作

即使准备再充分，生产环境也可能有“惊喜”。这里记录几个我踩过的坑和解决方法。

问题1：重启sshd失败，报错“Invalid configuration directive”

• 原因：配置文件中可能存在拼写错误（如Cipher少了s），或者在新版本中已废弃的指令。
• 解决：sshd -t命令会精确指出错误行。仔细检查修改过的行。确保指令名正确，并且值中的算法名称没有拼写错误（一个逗号或一个横杠错了都不行）。

问题2：服务能启动，但所有客户端都无法连接

• 原因：算法白名单过于严格，没有包含任何客户端支持的算法。或者，配置的算法虽然客户端支持，但服务器端OpenSSL库不支持（例如编译时缺少GCM支持）。
• 解决：
  1. 通过**之前准备的应急通道（控制台或备用SSH）**登录服务器。
  2. 临时将/etc/ssh/sshd_config中的算法配置注释掉（在行首加#），恢复为默认值。
  3. 重启sshd服务。先恢复连通性。
  4. 仔细检查sshd -T输出的默认算法列表，确保你选择的算法确实在其中。可以先用一个较宽松的白名单（如包含aes128-ctr, aes256-ctr等），再逐步收紧。

问题3：特定客户端（如某品牌网络设备）连接变慢或超时

• 原因：可能该客户端不支持我们首选的快速算法（如chacha20），或者密钥交换算法协商失败。有些老旧设备对curve25519支持不好。
• 解决：在sshd_config中调整算法顺序，把兼容性最广的aes128-ctr或aes256-ctr放到Ciphers列表的最前面。对于Kex，可以尝试把ecdh-sha2-nistp256或diffie-hellman-group-exchange-sha256放前面。

问题4：升级RPM包后，SELinux阻止启动

• 原因：新版本的sshd二进制文件或相关文件的安全上下文不正确。
• 解决：

  # 恢复文件的安全上下文 restorecon -Rv /etc/ssh /usr/sbin/sshd /usr/libexec/openssh/sftp-server # 如果还不行，可以临时将SELinux设为permissive模式排查 setenforce 0 systemctl restart sshd # 如果问题解决，说明是SELinux策略问题，需要生成并安装新的策略模块，或调整布尔值 # 查看audit日志：grep sshd /var/log/audit/audit.log | audit2why

回滚操作： 如果问题无法快速解决，需要立即回滚。

1. 通过应急通道登录。
2. 停止新版本服务：systemctl stop sshd。
3. 恢复备份的二进制文件（如果编译安装）：

   cp /root/ssh_backup_xxxx/sshd.bin.old /usr/sbin/sshd

4. 恢复备份的配置文件：

   cp /root/ssh_backup_xxxx/sshd_config /etc/ssh/

5. 重启服务：systemctl start sshd。 整个过程应该在几分钟内完成，将影响降到最低。

整个升级与加固过程，本质上是在安全性与兼容性之间寻找最佳平衡点。没有一劳永逸的配置，需要根据你的客户端生态定期审视和调整。我的经验是，每次OpenSSH发布重要安全更新后，都值得重新评估一次你的算法配置。把这份配置和操作流程文档化，纳入你的服务器基线标准，以后无论是新服务器上线还是老服务器巡检，都能做到心中有数，手中有策。