简介CentOS 7.9 环境下OpenSSH 与 SSL 库的安全升级一直是运维工作中的重点。面向需要修复 SSH 服务漏洞、提升远程管理安全水平的运维工程师这份资源提供了一套基于 RPM 的升级加固方案避免手动编译带来的依赖缺失、版本冲突与回滚困难。压缩包共 4 个文件包含 3 个 x86_64 的 RPM 安装包分别对应主程序、服务端与客户端以及 1 个 Shell 升级脚本整体大小约 20.42MB。脚本可在 CentOS 7.9 上自动完成 OpenSSH 10.0p1 与 SSL 3.5.1 的安装替换并支持禁用空密码登录、关闭 root 远程登录、设置空闲超时等加固项降低系统被非法访问的风险目前已有 140 人学习、下载。使用这份资源用户不仅能快速获得可直接安装的 RPM 包和升级脚本还能从脚本内容中理解旧版本备份、依赖处理、关键配置调整等完整思路便于在测试环境先行验证后按需二次定制是一份实用的系统安全加固参考。1. 为什么 CentOS 7.9 的 OpenSSH 升级加固不能再拖CentOS 7.9 自带的是 OpenSSH 7.4 和 OpenSSL 1.0.2k这两个版本在今天的漏扫报告里几乎是“必现高危”协议算法偏老、密码套件有 Sweet32 风险、一堆公开 CVE 都卡在这两套组件上。标题里的 “centos7.9-ssh10.0p1-ssl3.5.1-rpm-x86-64升级加固脚本”就是把 OpenSSH 升到 10.0p1、OpenSSL 升到 3.5.1并用 rpm 包在 x86_64 机器上完成安装和安全加固的一套落地流程。适合被安全整改追着走的运维也适合刚接手一堆 7.9 老机器、想一次性把 SSH 基线抬高的人。核心价值不只是“把版本号升上去”而是升级过程中每一步都留验证、留回滚不把自己锁在门外。2. 升级前必做的三件事版本兼容、rpm选择与系统备份2.1 先确认基线当前SSH/SSL版本与架构不能靠猜同一条升级加固脚本x86_64 和 aarch64 的 rpm 不通用CentOS 7.9 的不同小版本也可能有不同的编译依赖。所以脚本第一段动作不是安装而是把现状完整记录成一组基线文件。我一般会在操作前先跑一遍下面的命令# 记录系统版本、内核、架构 cat /etc/redhat-release uname -r uname -m # 当前 OpenSSH 与 OpenSSL 版本 ssh -V 21 | tee /tmp/pre_ssh_version.txt openssl version # 当前 sshd 生效配置与主机密钥清单 sshd -T 2/dev/null | head -n 20 ls -l /etc/ssh/ssh_host_*这里的 ssh -V 会把版本信息打到 stderr所以要 21 收一下tee 同时输出到终端和文件后面核对升级结果时直接 diff 这个文件。openssl version 如果输出 1.0.2k-fips说明是系统自带包如果输出 3.x说明这台机器已经被别人动过再跑升级脚本前必须重新评估。还有一个小坑某些云厂商镜像会预装自己编译的 sshdrpm -qa openssh 查不到包但 ssh 命令能用。这种情况必须先用rpm -qa | grep -E openssh|openssl确认安装来源否则后面 rpm -Uvh 很可能会因为包冲突直接失败。2.2 为什么必须用rpm而不是直接替换二进制很多人拿到源码第一反应是 make make install但这在 SSH 升级上属于“把黑匣子带进运维”编译安装没有 rpm 元数据之后卸载、升级、追踪版本全靠猜编译默认路径又在 /usr/local和系统自带的 /usr/bin/ssh 共存时PATH 一变就分不清当前用的是哪个版本。标题里明确给了 rpm 和 x86-64说明这套方案的目的是用标准 rpm 生命周期管理新旧组件脚本只负责安装顺序和配置加固把安装动作交给 rpm 完成。rpm 方式还有个直接好处加固后可以跑rpm -V openssh openssl校验哪些文件被改过、哪些文件权限异常。如果你之前是源码编译这个验证手段基本是废的。关于升级命令建议用 rpm -Uvh 而不是 rpm -ivh-U 在安装新包时会替换旧版本并把原来的配置保存成 .rpmsave-ivh 遇到已安装的包会直接报「package already installed」。如果拿到的是 openssh-server、openssh-clients 等多个互相依赖的包一次rpm -Uvh *.rpm让 rpm 自行处理依赖顺序比一个个敲要省事。提示rpm 是 CentOS 7.9 的包管理基础相当于 Debian/Ubuntu 里的 apt。如果哪台机器连rpm --version都跑不出来说明它根本不是标准 yum 环境这套脚本不能直接用。2.3 备份与回滚计划先给自己留后悔药升级 SSH 最怕的不是失败是失败后旧版本也不在了只能跑机房。备份至少要覆盖三层现有 rpm 包列表、sshd_config 与主机密钥、防火墙和 SELinux 里和 SSH 相关的规则。下面是脚本里建议的最小备份集mkdir -p /root/ssh_upgrade_backup/{rpm,etc} rpm -qa | grep -E openssh|openssl /root/ssh_upgrade_backup/rpm/rpm_list.txt cp -a /etc/ssh/sshd_config /root/ssh_upgrade_backup/etc/ cp -a /etc/ssh/ssh_host_* /root/ssh_upgrade_backup/etc/ cp -a /etc/pki/tls/openssl.cnf /root/ssh_upgrade_backup/etc/ 2/dev/null || true firewall-cmd --list-all /root/ssh_upgrade_backup/etc/firewall.txt 2/dev/null ss -tlnp | grep -E :22 /root/ssh_upgrade_backup/etc/firewall.txt主机密钥必须备份因为升级后如果重新生成 host key所有客户端的 known_hosts 都会失效ssh 批量登录、git 通过 ssh 认证都会变成“host key verification failed”。ssh_host_* 包括 rsa、ecdsa、ed25519 几套备份时用 cp -a 保留原始属主和权限。还有一处容易漏如果 sshd_config 里写了Include /etc/ssh/sshd_config.d/*.conf这个目录下的片段也要一起备份。备份完后建议把文件列表打印出来确认一下尤其是 ssh_host_rsa_key 的体积不是 0否则后面恢复时会踩坑。3. 把升级加固脚本拆开从安装到配置的完整流程3.1 安装顺序先OpenSSL后OpenSSH避免动态库错位OpenSSH 10.0p1 编译时链接的是 OpenSSL 3.x 的 libcrypto.so.3而 CentOS 7.9 系统自带 OpenSSL 1.0.2k 只有 libcrypto.so.10。如果先装 OpenSSHsshd 启动时会因为找不到新库直接崩。所以标准动作是先装 OpenSSL 3.5.1确认新库在位再装 OpenSSH。但这里有一个关键决策要不要让新 OpenSSL 直接替换系统自带的软链接我的建议是不要。CentOS 7.9 的 yum、curl、python、mysql client 都依赖 1.0.2k 的 libssl.so.10你把它顶掉整个基础工具链都会跟着翻车——常见现象是升级后yum list报libcrypto.so.10: cannot open shared object filepip 也会报ssl support is missing。更稳的做法是让 OpenSSL 3.5.1 以独立目录安装比如 /usr/local/sslOpenSSH 编译时用--with-ssl-dir指过去。这样新旧两套库各管各的不会互相踩。安装命令的大致形态如下# 安装 OpenSSL 3.5.1假设 rpm 包已经按 /usr/local/ssl 前缀打包 rpm -Uvh /path/to/openssl-3.5.1-1.el7.x86_64.rpm # 确认新动态库与二进制在位 ls -l /usr/local/ssl/lib64/libcrypto.so.3 /usr/local/ssl/bin/openssl version说明/usr/local/ssl 是源码编译时 --prefix 的常见值如果你的 rpm 包不是这个路径以rpm -ql openssl为准。之所以强调路径是因为很多网上的“一键升级”rpm 包会把新库直接装进 /usr/lib64然后软链接覆盖成 libcrypto.so.3那种包安装后系统立刻出现“yum 坏了、curl 坏了”的现象。所以在安装前一定要检查文件清单确认新 OpenSSL 没有覆盖系统库。检查命令是rpm -qpl openssl-3.5.1-1.el7.x86_64.rpm | grep -E libcrypto|libssl安装 OpenSSH 的步骤类似同样要注意 rpm 包里 sshd_config 的默认路径是否还是 /etc/ssh/sshd_config以及是否带了 systemd unit 文件。命令如下# 安装 OpenSSH不覆盖系统旧配置 rpm -Uvh /path/to/openssh-10.0p1-1.el7.x86_64.rpm \ /path/to/openssh-server-10.0p1-1.el7.x86_64.rpm \ /path/to/openssh-clients-10.0p1-1.el7.x86_64.rpm说明rpm -Uvh 在替换旧包时会把旧配置文件改名成 .rpmsave。升级后第一件事就是检查 /etc/ssh/sshd_config.rpmsave把里面自定义的端口、AllowUsers 等内容手动迁移到新配置里不能指望 rpm 自动合并。OpenSSH 从 8.x 开始默认算法持续收窄旧配置里的一些 AllowTcpForwarding、UseDNS 写法虽然还在但语义可能有变化直接硬覆盖进新配置可能让 sshd 拒绝启动。3.2 加固sshd_config协议、密钥、算法、登录策略一次配齐升级后的默认 sshd_config 通常已经比旧版安全但距离等保和漏扫要求还差几步。我习惯把加固项单独写到 /etc/ssh/sshd_config.d/hardening.conf而不是直接改主配置这样以后再来一轮安全整改时只需要替换这一个文件。前提是主配置里要有Include /etc/ssh/sshd_config.d/*.conf一行CentOS 7.9 的默认配置已经有这行了但如果你手工改过主配置需要确认一下。cat /etc/ssh/sshd_config.d/hardening.conf EOF # 主机密钥只保留 RSA/ECDSA/Ed25519禁用 DSA HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key # 登录策略公钥认证优先禁止空密码 PermitRootLogin prohibit-password PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no # 密钥交换与加密算法去掉 SHA1 和弱曲线 KexAlgorithms curve25519-sha256,curve25519-sha256libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512 Ciphers chacha20-poly1305openssh.com,aes256-gcmopenssh.com,aes128-gcmopenssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-256-etmopenssh.com,hmac-sha2-512-etmopenssh.com # 连接超时与爆破防护 MaxAuthTries 3 LoginGraceTime 30 ClientAliveInterval 300 ClientAliveCountMax 2 # 转发控制除非确有必要全关 AllowTcpForwarding no AllowAgentForwarding no X11Forwarding no EOF参数说明PermitRootLogin 我这里写的是 prohibit-password意思是 root 允许登录但只能通过密钥密码完全不能进。如果你是内部跳板机加上严格 ACL可以再收紧成 no。MaxAuthTries 3 和 LoginGraceTime 30 是扫描器判定暴力破解防护是否到位的两个关键项。ClientAliveInterval 300 配合 ClientAliveCountMax 2能在客户端“假死”时自动断开连接避免系统里挂一堆空闲 sshd 进程。很多人在 vscode 里设置“连接 ssh 远程服务器后十分钟不用就断线”其实就是服务端这两个值没配对到预期效果。算法这一排很容易引发“配了强算法结果连不上”的争议。KexAlgorithms 只保留 curve25519 和 diffie-hellman-group16/18老客户端如果只支持 group14协商就会失败。Ciphers 去掉 aes128-cbc、3des-cbc是为了规避 Sweet32 这类针对 64 位块大小密码套件的碰撞攻击。如果你环境里有老堡垒机或老网络设备建议把 diffie-hellman-group14-sha256 也加回来作为管理网段的降级兜底。这个稍后在避坑部分详细说。3.3 端口与SELinux改端口不是改一行配置的事升级到 10.0p1 后把 SSH 端口从 22 改为高位端口是常见的加固动作能降低被批量扫描的概率。但只改 sshd_config 里的 Port 是不够的至少要同步处理三件事sshd_config 的监听端口、firewalld 防火墙放行、SELinux 的端口标签。前两者漏掉端口不通SELinux 漏掉sshd 可能“看起来启动成功”但连接直接被拒绝。下面是脚本里这一段的典型写法# 修改配置里的端口这里以 22022 为例 sed -i s/^#Port 22/Port 22022/ /etc/ssh/sshd_config.d/hardening.conf # firewalld 放行新端口并移除默认 ssh 服务 firewall-cmd --permanent --add-port22022/tcp firewall-cmd --permanent --remove-servicessh firewall-cmd --reload # SELinux 放行 SSH 新端口 semanage port -a -t ssh_port_t -p tcp 22022参数说明semanage 来自 policycoreutils-python 包CentOS 7.9 默认可能没装缺的话先yum install -y policycoreutils-python。改完端口后要同时检查云控制台的安全组、内网的 iptables 规则否则本地放行了云上没放行一样连不上。改端口还会影响已有的 ssh 批量登录任务和 git remote 配置所有地方都要同步更新端口号。否则会出现“ssh 认证失败 git 突然开始报错”这种看起来像密钥坏了、实际是端口没改的乌龙。4. 升级后验证清单服务可起、算法生效、远程能连4.1 服务与端口验证systemctl 和 ssh -V 双确认升级完不能只看 rpm -qa 里有新版本就认为成功必须验证 sshd 能持续运行。我的顺序是先跑配置语法检查再在前台用 debug 模式启动一两次最后才交给 systemd 重启。注意新版 sshd 的-t只能检查语法检查不了 SELinux 上下文和密钥权限这些要在服务真正启动时才暴露。# 配置语法检查 /usr/sbin/sshd -t # 前台 debug 模式看到监听端口和 host key 加载成功后 CtrlC /usr/sbin/sshd -ddd -p 22022 # 交回 systemd systemctl restart sshd systemctl status sshd --no-pager # 版本确认 ssh -V openssl version ls -l /usr/local/ssl/lib64/libcrypto.so.3说明sshd -ddd 会把每一次密钥交换、每一个 host key 加载都打印到终端能直接判断是配置问题还是依赖库问题。ssh -V 的输出里会有 OpenSSH_10.0p1 和 OpenSSL 3.5.1 这样的字段。如果 ssh -V 显示 OpenSSL 还是 1.0.2说明 sshd 并没有链接新的 libcrypto需要再执行ldd /usr/sbin/sshd | grep ssl确认。这是升级后最容易被忽略的“版本显示已到位实际没生效”问题。4.2 算法协商验证用 ssh -vvv 看Kex和Ciphers配置了强算法后最担心的不是配置本身而是“配置了但没被读取”。验证算法是否生效我喜欢用另一台机器发起一次 ssh -vvv直接看协商过程里最终选中的密钥交换、哈希和加密算法。命令如下# 在另一台机器上执行观察协商中实际使用的算法 ssh -vvv -p 22022 root目标机器 21 | grep -E KEX|host key|kex_parse|Ciphers|MACsgrep 输出里如果有你配置里没出现的算法说明 sshd 没读到 hardening.conf或者配置片段被主配置里的后面项覆盖了。常见的覆盖来源有两个一是 sshd_config 主文件中存在另外的 KexAlgorithms/Ciphers/MACs 行二是 Include 语句放在了主文件的末尾但后面还有别的子文件被加载。检查方法grep -nE Include|KexAlgorithms|Ciphers|MACs /etc/ssh/sshd_config另外OpenSSH 10.0p1 自带了ssh -Q kexalgorithms、ssh -Q ciphers、ssh -Q macs这三个查询命令可以用它直接列出当前二进制支持的算法全集。这个全集比配置里列出的要多属于正常现象不用担心。升级后如果机器上还跑着 nginx、nacos 这类需要配置 ssl 证书的中间件也要顺手检查一遍它们的 SSL 库链接特别是新版本 OpenSSL 的证书校验策略和旧版有差异可能出现“openssl 升级后 ssl 连接错误”的情况。4.3 重启不掉线的技巧tmux 安全会话升级和重启 sshd 最怕的是当前连接断掉。实际上重启 sshd 通常不会切断已有连接因为旧进程会继续服务已建立的会话但如果你同时改了端口、禁用了密码登录、重建了 host key当前连接也可能被波及。我的铁律是所有修改 sshd 的步骤都放在 tmux 会话里执行并且提前把备用密钥放到另一台机器上。# 当前连接里开一个 tmux 会话 tmux new -s ssh_upgrade # 如果连接意外断开重新登录后在任意终端恢复会话 tmux attach -t ssh_upgrade提示在使用 tmux 的基础上还要确保手里至少有两把能登录的密钥一把留在本地一把放到内网跳板机或另一台管理机。血泪教训是在 hardening.conf 里把 PasswordAuthentication 设为 no 后突然发现自己唯一的私钥权限不对密码登录又被禁用整台机器只剩控制台一条路。5. 避坑升级OpenSSH时最常见的5个翻车现场5.1 升级 OpenSSL 后 yum 报错libcrypto.so.10 不见了现象执行 rpm -Uvh openssl-3.5.1 后再跑 yum list 直接报python: error while loading shared libraries: libcrypto.so.10: cannot open shared object filecurl、wget 也一起失效。原因新 OpenSSL 的 rpm 包把 libcrypto.so.3 装进了 /usr/lib64并在安装时替换或删除了系统原有的 libcrypto.so.10 软链接。CentOS 7.9 的 python、yum、curl 都链接旧库所以整个基础工具链立刻崩掉。更麻烦的是有些 rpm 包为了“兼容”安装时直接覆盖了系统软链接让你以为新旧共存其实旧的已经没了。解决如果新 OpenSSL 已经污染了系统库先用备份的旧 rpm 包强制恢复rpm -Uvh --replacepkgs --oldpackage /root/ssh_upgrade_backup/rpm/openssl-1.0.2k-*.rpm这里的关键参数是 --oldpackage允许用旧版本覆盖新版本否则 rpm 会提示“已安装更新版本”。恢复后确认openssl version回到 1.0.2k再重新把新 OpenSSL 以独立目录方式安装。正确的安装方式可以避免这个坑装新包前用rpm -qpl检查文件路径确认新库进入 /usr/local/ssl 而不是 /usr/lib64。如果机器上还跑着 mysql、dify 这类依赖 SSL 的服务升级后也要重点看它们链接的是哪个 libssl避免“mysql ssl 连接错误”这类连锁故障。5.2 sshd 重启后连接被拒绝主机密钥权限与上下文现象systemctl restart sshd 状态显示 active但远程连接时报no hostkeys available或者 ssh 客户端提示 host key verification failed。用 sshd -t 检查却没有输出错误。原因旧主机密钥从备份目录恢复后权限可能变成了 0644或者 SELinux 上下文因为文件被移动而丢失。新版 OpenSSH 对 host key 文件权限检查很严格要求 0600 且属主是 root。SELinux 开启时文件上下文必须是 sshd_key_t否则 sshd 在读取阶段就会被拒绝。解决恢复密钥后统一刷权限和上下文chmod 600 /etc/ssh/ssh_host_* chown root:root /etc/ssh/ssh_host_* restorecon -Rv /etc/ssh systemctl restart sshd如果主机密钥备份缺失最简单是删掉旧密钥让 sshd 自动重新生成但这样所有客户端的 known_hosts 都要重建。注意新生成的密钥默认会包含 ed25519老客户端如果只支持 RSA需要确认 rsa host key 仍在 /etc/ssh 下否则老客户端会连接失败。5.3 密码登录被禁但密钥又没配对血泪教训现象加固配置里写了 PasswordAuthentication no重载后密码登录全部失败密钥登录也失败提示 Permission denied。用 ssh -vvv 能看到服务端接受了公钥但客户端始终过不了认证。原因多数情况下是客户端私钥权限太宽松。OpenSSH 7.8 之后开始检查私钥文件权限如果 ~/.ssh/id_rsa 是 0644会直接拒绝使用。服务端配置没问题但客户端私钥不合法导致认证中断。还有一种可能known_hosts 里的旧 host key 和新 key 不匹配客户端在确认新 host key 时中断看起来像认证失败。解决在客户端上先修正私钥权限再清理旧 host keychmod 600 ~/.ssh/id_rsa ssh-keygen -R 目标机器IP -p 22022 2/dev/null || true ssh -p 22022 root目标机器IP这里的 -R 是移除旧 host key下一次连接时会弹出新 key 确认。如果你用的是 pssh、ansible 这类批量登录工具也要同步检查它们使用的私钥路径和权限。这个坑在升级后“ssh 认证失败 git”的场景里尤其常见——git 操作看着是密钥失效实际是私钥权限或 host key 不匹配。5.4 配置了强算法却发现客户端连不上兼容性边界现象KexAlgorithms 和 Ciphers 收紧后老客户端直接报no matching key exchange method found或no matching cipher found。原因Xshell、PuTTY 旧版本以及老系统的 OpenSSH 7.3 等只支持 diffie-hellman-group14-sha1、aes128-cbc 这类已经被禁用的弱算法。安全加固把弱算法全禁掉老工具自然协商失败。解决从安全角度可以保留一组降级算法但限制来源网段。用 Match Address 指令把弱算法只开放给管理网段这样全局不暴露弱算法内网老工具又能正常连cat /etc/ssh/sshd_config.d/hardening.conf EOF Match Address 192.168.0.0/16 KexAlgorithms diffie-hellman-group14-sha256 Ciphers aes128-ctr,aes192-ctr,aes256-ctr EOF参数说明行首的 号表示在全局配置基础上追加而不是替换。如果你的合规要求是全段都不能出现弱算法就只能强制客户端升级或者用 ssh -o KexAlgorithms... 在客户端手工指定算法。这个坑提醒我们任何加固粒度都要先把“能连”作为第一优先级再谈强弱。5.5 SELinux 拦截新端口sshd 起不来却看不到报错现象把端口改到 22022 后systemctl status sshd 显示 active但客户端始终连接不上。journalctl -u sshd 也没有明显错误。原因SELinux 强制模式下sshd 只被允许监听带有 ssh_port_t 标签的端口。新端口没有打标签SELinux 会静默拦截systemd 层面却认为服务已启动。查看ausearch -m avc -ts recent能看到 AVC denial。解决用 semanage 把新端口加入 ssh_port_tsemanage port -l | grep ssh_port_t semanage port -a -t ssh_port_t -p tcp 22022注意如果机器上没有 semanage很多人会直接setenforce 0关闭 SELinux。这是为了修一条规则把整堵墙拆了不推荐。正确做法是安装 policycoreutils-python只补加一条端口规则。改完端口后还要记得在云安全组里同步放行否则本地规则加好了远端云平台没放行依然连不上。6. 收尾做一个一键回滚脚本把升级失败的成本降到最低升级到这里基本完成但真正让运维敢在生产环境执行的是留一条退路。我习惯在脚本最后自动生成一个 rollback.sh内容不复杂但能救急备份目录里留着一整套旧 rpm回滚脚本只需要停掉新版本、恢复旧 rpm 和旧配置。cat /root/ssh_upgrade_backup/rollback.sh EOF #!/bin/bash # 回滚脚本升级后无法连接或服务异常时应急恢复 set -e BACKUP/root/ssh_upgrade_backup echo 停止新版 sshd防止旧包恢复后被新进程占用 systemctl stop sshd systemctl disable sshd 2/dev/null || true echo 用旧 rpm 包降级回恢复 rpm -Uvh --replacepkgs --oldpackage \ $BACKUP/rpm/openssl-*.rpm \ $BACKUP/rpm/openssh-*.rpm 2/dev/null || { echo rpm 恢复失败请从原始介质补齐旧包 exit 1 } echo 恢复 sshd_config 与主机密钥 cp -a $BACKUP/etc/sshd_config /etc/ssh/sshd_config cp -a $BACKUP/etc/ssh_host_* /etc/ssh/ restorecon -Rv /etc/ssh 2/dev/null echo 清理新端口防火墙与 SELinux 规则 firewall-cmd --permanent --remove-port22022/tcp 2/dev/null || true systemctl restart firewalld 2/dev/null || true echo 启动旧版 sshd systemctl enable sshd systemctl start sshd ss -tlnp | grep -E :22 || echo 22 端口未监听请手动检查 EOF chmod x /root/ssh_upgrade_backup/rollback.sh这个脚本里最关键的是 --oldpackage它允许旧版本 rpm 覆盖新版本否则 rpm 会拒绝降级。备份目录里如果没有完整保留旧 rpm 包回滚就是空话。我自己的习惯是每次升级完先检查回滚脚本里的端口号是否匹配再把整个备份目录压缩成 tar 包扔到内网独立存储上。真出事时我宁可多花五分钟回滚也绝不现场去看“为什么 sshd 起不来”。这套流程走过几次之后回滚脚本在我心里的优先级早就超过了升级脚本本身。希望帮到你。本文还有配套的精品资源点击获取