每次在安全扫描报告里看到一堆SSH高危漏洞我脑子里第一反应就是又是OpenSSH版本太老。CentOS 7.x自带OpenSSH 7.4p1这版本从2016年到现在被CVE追着打了无数轮什么用户枚举、整数溢出、降级攻击全占了。但麻烦的是官方源里一直不更新openssh老老实实yum update根本等不来新版。所以只能自己动手把openssh从7.4p1升级到8.4p1。这个操作听起来简单实际上坑不少。如果是在只能远程登录的服务器上操作稍不留神sshd起不来整个人就得从IDC机房排队等物理机重启那种绝望感我体会过不止一次。所以这篇就把完整流程、备份保命手段、编译参数、常见报错全部整理出来。适合需要做等保整改、日常安全加固或者纯粹想在CentOS 7/RHEL 7.x上把SSH老版本换掉的朋友直接参考。1. 升级前的准备先想清楚再动手1.1 这次升级到底解决了什么问题OpenSSH 7.4p1这个版本有多个已知安全缺陷其中比较典型的有几个CVE-2018-15473远程用户枚举漏洞攻击者可以在未授权状态下通过时间差异猜测系统用户名给暴力破解省了一半力气。CVE-2019-16905存在于X11转发和Agent转发功能里的整数溢出远程代码执行级别虽然利用条件没那么简单但扫描器可不管你利用成本。CVE-2020-14145客户端明文密码探测主要是针对使用旧算法协商的连接存在降级攻击风险。等保2.0测评项里对SSH协议版本有明确要求7.4这种老版本基本属于必报项目不管漏洞可不可利用看到就该升。OpenSSH 8.4p1是2020年9月发布的稳定版虽然也不是最新但至少把上述高危项都修了个干净在安全扫描里能顺利过关。如果你系统里openssl是1.0.2k-fips版本跟8.4p1的依赖也完全兼容不需要连openssl一起折腾。1.2 先确认系统环境和当前版本升级前先把家底摸清楚用下面三条命令确认系统发行版本、内核以及当前openssh版本cat /etc/redhat-release uname -r ssh -V正常情况下你会看到类似这样的输出CentOS Linux release 7.9.2009 (Core) 3.10.0-1160.el7.x86_64 OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017如果是RHEL或麒麟等跟CentOS 7.x同源的系统操作基本一致。内核版本不同影响不大但最好确保系统有正常的yum源能装依赖包否则后续编译工具链都装不上。1.3 提前评估远程升级的风险这一步我必须单独拎出来说因为坑主要就在这。OpenSSH是远程登录的生命线升级过程中一旦编译错、配置错、或者替换二进制后服务起不来而你只有这一条远程通道那就只能让机房的同事帮你重启物理机了。如果机器在异地机房、没人协助基本等于运维事故。所以我的铁律是远程服务器升级SSH必须先保证有第二把钥匙。一般有两种做法开启telnet-server作为临时应急通道明文传输用完立刻关用带外管理IPMI/iLO如果有的话保底如果都不具备至少要在screen或tmux会话里执行升级操作。这样网络闪断的话连接断了但会话还在重新登录还能找回旧会话不至于让升级任务跟着断掉。2. 搭建应急通道与编译环境2.1 临时开启telnet保命虽然telnet不加密被人抓包能看到密码但作为几分钟内的应急通道是值得的。开启后记得在防火墙层面限制来源IP只放行你当前所在网段避免被全网扫描器撞到。# 安装telnet服务端和客户端 yum install -y telnet-server telnet # 启动telnet socketCentOS 7使用socket激活方式 systemctl enable telnet.socket systemctl start telnet.socket然后确认23端口在监听ss -tlnp | grep 23如果系统开启了firewalld还要放行一下firewall-cmd --permanent --add-rich-rulerule familyipv4 source address你的管理网段/24 port port23 protocoltcp accept firewall-cmd --reloadtelnet起来后建议先开一个新窗口用telnet登录一次确认能够正常进入系统再继续下面的操作。这也算一种先验证逃生路线再进隧道的思路。2.2 安装编译依赖包源码编译需要一整套工具链和库文件一次性装齐避免configure阶段缺东少西yum install -y gcc gcc-c make autoconf automake libtool zlib zlib-devel openssl openssl-devel pam-devel rpm-build这里简单说下每个依赖的作用gcc、gcc-c编译C/C源码的基础编译器。zlib-devel提供压缩库头文件OpenSSH传输数据时要用到zlib压缩。openssl-devel提供加密算法库头文件SSH握手、会话加密都依赖它。pam-devel提供PAM认证开发文件如果不想编译出的sshd无法进行系统账户认证必须带上这个。automake、libtool等部分组件编译时会调用一并装上省心。装完后可以用下面的命令验证编译环境是否okgcc --version make --version确认正常输出版本信息后再进入下一步。别小看这一步我有一次就是少了pam-develconfigure能过但启动sshd后怎么都用系统密码登录不进去折腾半天最后重编才解决。2.3 下载OpenSSH 8.4p1源码包到OpenBSD官方CDN下载portable版源码包这是最干净的获取方式。如果服务器是纯内网环境可以在有外网的机器上下载再传到服务器上。cd /usr/local/src wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.4p1.tar.gz tar -zxvf openssh-8.4p1.tar.gz cd openssh-8.4p1下载后可以做一步校验避免源文件被篡改或传输损坏sha256sum openssh-8.4p1.tar.gz与官方发布的SHA256值核对一致后再解压使用。这一步在生产环境尤为重要安全软件从下载就要开始把关。3. 编译安装关键参数一个都不能少3.1 configure参数详解进入解压后的目录执行如下configure命令./configure --prefix/usr --sysconfdir/etc/ssh --with-pam --with-zlib --with-md5-passwords --with-privsep-path/var/empty/sshd把这些参数逐个说明清楚参数作用--prefix/usr指定安装目录为/usr这样sshd会装到/usr/sbin/sshdssh装到/usr/bin/ssh直接覆盖系统原文件避免PATH里出现两个版本--sysconfdir/etc/ssh配置文件仍然放到/etc/ssh跟系统原有路径保持一致不破坏现有目录习惯--with-pam启用PAM认证。这个是重中之重没有它系统用户通过SSH登录时会直接认证失败--with-zlib启用zlib压缩支持对应CentOS自带的zlib-devel--with-md5-passwords兼容MD5密码哈希格式老系统用户密码有部分是MD5存储的不加上可能无法认证--with-privsep-path/var/empty/sshd指定权限分离目录sshd会在这里以低权限运行子进程这里我特意用了--prefix/usr而不是常见的/usr/local原因很简单源码安装默认路径是/usr/local那样的话新版本文件在/usr/local/sbin/sshd而系统原有旧版本还在/usr/sbin/sshd你重启服务后系统调用的仍然是旧版等于白忙一场。虽然可以手动做软链接但不如直接统一安装路径来得干净。3.2 configure报错的处理如果你看到类似这样的提示checking OpenSSL header version... not found. checking OpenSSL library version... not found.说明openssl-devel没装回头执行yum install -y openssl-devel再重新configure。如果提示缺少其他头文件按提示补装对应的-devel包就行。还有一种情况是系统里同时存在多个openssl版本导致头文件和库版本不一致可以通过参数指定路径./configure --prefix/usr --with-ssl-dir/usr/local/ssl ...一般CentOS 7不会遇到这种问题不必过度处理。3.3 make编译与安装configure成功后会生成Makefile接下来执行make -j4 make install-j4是按4个并行任务编译如果你的CPU核数多于4可以调大编译速度快不少。如果make中途报错看看错误信息里有没有提示conflicting types或undefined reference这类问题大多是依赖库版本太老或编译器版本太旧。CentOS 7自带的gcc 4.8.5编译OpenSSH 8.4p1是没问题的不必折腾升级gcc。make install执行完成后/usr/sbin/sshd和/usr/bin/ssh这些核心二进制已经被替换为8.4p1版本。如果不放心可以用ls -l看下时间戳确认文件确实被更新了。这里建议在编译前先备份原文件cp /usr/sbin/sshd /usr/sbin/sshd.bak.7.4p1 cp /usr/bin/ssh /usr/bin/ssh.bak.7.4p1一旦升级后出现问题可以快速用备份文件还原。3.4 处理权限分离目录在启动新sshd之前确认权限分离目录存在且权限正确mkdir -p /var/empty/sshd chmod 755 /var/empty/sshd chown root:root /var/empty/sshd如果这个目录不存在或者权限不对sshd可能会拒绝启动并报错。很多第一次编译安装的朋友都会卡在这里其实是这个细节没注意。4. 配置调整与服务重启4.1 生成主机密钥新版本sshd启动时如果发现/etc/ssh下缺少主机密钥一般会自动生成。但为了让控制更可控我还是推荐手动统一生成一次ssh-keygen -A这条命令会生成rsa、ecdsa、ed25519三种算法的主机密钥分别对应/etc/ssh/ssh_host_rsa_key、ssh_host_ecdsa_key、ssh_host_ed25519_key。如果你之前的主机密钥还在这个命令会跳过已存在的文件不会覆盖。生成后要确保权限正确chmod 0600 /etc/ssh/ssh_host_*_key chmod 0644 /etc/ssh/ssh_host_*_key.pub chown root:root /etc/ssh/ssh_host_*_key主机密钥权限不对sshd启动时会提示Permissions too open之类的报错。这是另一个高频踩坑点。4.2 编辑sshd_config升级后原有的/etc/ssh/sshd_config仍可用因为OpenSSH 8.4的配置语法向后兼容大多数7.4的配置项还认识。但有几个点要留意如果原配置里启用了RSA/SHA1签名算法而你的客户端老比如Windows 7上的老版本PuTTY建议在sshd_config中显式加上HostKeyAlgorithms ssh-rsa PubkeyAcceptedKeyTypes ssh-rsa虽然8.4里这些算法仍在默认支持列表里但显式声明能避免后续升级到更高版本时突然失效。建议允许X11转发、Agent转发的场景确认配置里没有使用已废弃的选项。启动sshd前用-t参数检查配置是最稳妥的/usr/sbin/sshd -t如果配置有语法错误会直接打印出出错行号和原因这个检查非常值得养成习惯。另外可以顺手开启更安全的心跳和超时配置ClientAliveInterval 60 ClientAliveCountMax 3 MaxAuthTries 3 PermitRootLogin prohibit-password这些不是升级必须的但既然都在动sshd就一起加固了。注意PermitRootLogin如果设了prohibit-passwordroot用户只允许密钥登录确认服务器已经有可用的公钥之后再做这个改动否则自己可能把自己锁在外面。4.3 重启sshd服务确认配置无误后开始重启服务systemctl restart sshd systemctl status sshd如果看到active (running)的状态说明服务成功拉起。这时候别急着关当前SSH窗口最好新开一个会话连接测试确认新会话能正常登录再把旧的会话关闭。这是远程操作SSH升级的黄金习惯。4.4 验证升级结果用下面命令确认实际生效的OpenSSH版本/usr/sbin/sshd -V 21 ssh -V 21也可以直接看监听的sshd进程ss -tlnp | grep sshd升级成功后会显示OpenSSH_8.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017同时建议完整测试一下ssh、scp、sftp这几个日常功能避免只验证了登录通道回头传输文件时才发现问题。5. 升级后的巩固与常见问题排查5.1 整个升级过程中容易踩的五个坑我把近几年帮人排障遇到的高频问题集中列出来大家直接对照即可现象可能原因解决办法sshd启动失败提示Missing privilege separation directory/var/empty/sshd不存在按上文mkdir并设置好权限sshd启动失败提示Bad permissions on host key主机密钥权限太开放chmod 0600 主机私钥文件登录时提示PAM认证失败configure时没加--with-pam重新编译并带上该参数客户端连接提示REMOTE HOST IDENTIFICATION HAS CHANGED主机密钥发生了变化在客户端执行ssh-keygen -R 服务器IP重启后SSH连接被拒SELinux或防火墙拦截检查audit日志和firewalld规则5.2 如果升级后sshd真起不来了怎么办这是每个远程操作者最怕的场景。真遇到时先不要慌按顺序排查第一步如果telnet应急通道还开着先用telnet登进系统。第二步手动执行sshd看报错/usr/sbin/sshd -t根据报错修改配置。如果问题解决重新拉起服务systemctl start sshd第三步如果配置文件怎么都调不对直接用备份的sshd_config先回退cp /etc/ssh/sshd_config.rpmnew /etc/ssh/sshd_config 2/dev/null或者从源码包中复制默认配置cp /usr/local/src/openssh-8.4p1/sshd_config /etc/ssh/sshd_config第四步如果二进制文件本身有问题把编译前的备份还原cp /usr/sbin/sshd.bak.7.4p1 /usr/sbin/sshd systemctl start sshd回退成功后再找原因别在没把握的情况下反复试错。5.3 彻底关闭telnet应急通道确认新ssh已经完全正常、多次重连测试都稳定之后一定要第一时间把telnet去掉不然等于给机房开了个后门systemctl stop telnet.socket systemctl disable telnet.socket如果你是通过firewalld放行了23端口也一并移除规则firewall-cmd --permanent --remove-servicetelnet firewall-cmd --reload这一步我见过太多人忘掉升级完成一周后扫内网发现23端口的telnet还开着风险一点不比旧版SSH小。应急通道是万不得已才临时启用的用完必须清干净。5.4 后续建议把升级结果固化到运维文档最后给个小建议升级完成后把这次操作记录整理进运维变更单包含升级前版本、升级后版本、编译参数、重启时间、验证结果。特别是编译参数建议写上注释不然三个月后你自己回看都不知道当时为什么要加--with-md5-passwords。另外如果公司有配置管理工具Ansible一类把sshd_config和编译参数固化成标准模板下批次服务器做同样升级时可以直接复用省时省力。按这个流程操作下来从7.4p1到8.4p1的升级其实是一个很成熟的过程只要备份到位、应急通道开着、配置参数不手滑基本不会有意外。真出问题的时候记住三步走telnet进系统、sshd -t查配置、备份文件回退。把这套逻辑想通以后升9.x、10.x也就是换一个版本号的事。