簡介CentOS 7.9 環(huán)境下OpenSSH 與 SSL 庫的安全升級一直是運維工作中的重點。面向需要修復 SSH 服務漏洞、提升遠程管理安全水平的運維工程師這份資源提供了一套基于 RPM 的升級加固方案避免手動編譯帶來的依賴缺失、版本沖突與回滾困難。壓縮包共 4 個文件包含 3 個 x86_64 的 RPM 安裝包分別對應主程序、服務端與客戶端以及 1 個 Shell 升級腳本整體大小約 20.42MB。腳本可在 CentOS 7.9 上自動完成 OpenSSH 10.0p1 與 SSL 3.5.1 的安裝替換并支持禁用空密碼登錄、關閉 root 遠程登錄、設置空閑超時等加固項降低系統(tǒng)被非法訪問的風險目前已有 140 人學習、下載。使用這份資源用戶不僅能快速獲得可直接安裝的 RPM 包和升級腳本還能從腳本內(nèi)容中理解舊版本備份、依賴處理、關鍵配置調(diào)整等完整思路便于在測試環(huán)境先行驗證后按需二次定制是一份實用的系統(tǒng)安全加固參考。1. 為什么 CentOS 7.9 的 OpenSSH 升級加固不能再拖CentOS 7.9 自帶的是 OpenSSH 7.4 和 OpenSSL 1.0.2k這兩個版本在今天的漏掃報告里幾乎是“必現(xiàn)高?！眳f(xié)議算法偏老、密碼套件有 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選擇與系統(tǒng)備份2.1 先確認基線當前SSH/SSL版本與架構(gòu)不能靠猜同一條升級加固腳本x86_64 和 aarch64 的 rpm 不通用CentOS 7.9 的不同小版本也可能有不同的編譯依賴。所以腳本第一段動作不是安裝而是把現(xiàn)狀完整記錄成一組基線文件。我一般會在操作前先跑一遍下面的命令# 記錄系統(tǒng)版本、內(nèi)核、架構(gòu) 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 同時輸出到終端和文件后面核對升級結(jié)果時直接 diff 這個文件。openssl version 如果輸出 1.0.2k-fips說明是系統(tǒng)自帶包如果輸出 3.x說明這臺機器已經(jīng)被別人動過再跑升級腳本前必須重新評估。還有一個小坑某些云廠商鏡像會預裝自己編譯的 sshdrpm -qa openssh 查不到包但 ssh 命令能用。這種情況必須先用rpm -qa | grep -E openssh|openssl確認安裝來源否則后面 rpm -Uvh 很可能會因為包沖突直接失敗。2.2 為什么必須用rpm而不是直接替換二進制很多人拿到源碼第一反應是 make make install但這在 SSH 升級上屬于“把黑匣子帶進運維”編譯安裝沒有 rpm 元數(shù)據(jù)之后卸載、升級、追蹤版本全靠猜編譯默認路徑又在 /usr/local和系統(tǒng)自帶的 /usr/bin/ssh 共存時PATH 一變就分不清當前用的是哪個版本。標題里明確給了 rpm 和 x86-64說明這套方案的目的是用標準 rpm 生命周期管理新舊組件腳本只負責安裝順序和配置加固把安裝動作交給 rpm 完成。rpm 方式還有個直接好處加固后可以跑rpm -V openssh openssl校驗哪些文件被改過、哪些文件權(quán)限異常。如果你之前是源碼編譯這個驗證手段基本是廢的。關于升級命令建議用 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 環(huán)境這套腳本不能直接用。2.3 備份與回滾計劃先給自己留后悔藥升級 SSH 最怕的不是失敗是失敗后舊版本也不在了只能跑機房。備份至少要覆蓋三層現(xiàn)有 rpm 包列表、sshd_config 與主機密鑰、防火墻和 SELinux 里和 SSH 相關的規(guī)則。下面是腳本里建議的最小備份集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 保留原始屬主和權(quán)限。還有一處容易漏如果 sshd_config 里寫了Include /etc/ssh/sshd_config.d/*.conf這個目錄下的片段也要一起備份。備份完后建議把文件列表打印出來確認一下尤其是 ssh_host_rsa_key 的體積不是 0否則后面恢復時會踩坑。3. 把升級加固腳本拆開從安裝到配置的完整流程3.1 安裝順序先OpenSSL后OpenSSH避免動態(tài)庫錯位OpenSSH 10.0p1 編譯時鏈接的是 OpenSSL 3.x 的 libcrypto.so.3而 CentOS 7.9 系統(tǒng)自帶 OpenSSL 1.0.2k 只有 libcrypto.so.10。如果先裝 OpenSSHsshd 啟動時會因為找不到新庫直接崩。所以標準動作是先裝 OpenSSL 3.5.1確認新庫在位再裝 OpenSSH。但這里有一個關鍵決策要不要讓新 OpenSSL 直接替換系統(tǒng)自帶的軟鏈接我的建議是不要。CentOS 7.9 的 yum、curl、python、mysql client 都依賴 1.0.2k 的 libssl.so.10你把它頂?shù)粽麄€基礎工具鏈都會跟著翻車——常見現(xiàn)象是升級后yum list報libcrypto.so.10: cannot open shared object filepip 也會報ssl support is missing。更穩(wěn)的做法是讓 OpenSSL 3.5.1 以獨立目錄安裝比如 /usr/local/sslOpenSSH 編譯時用--with-ssl-dir指過去。這樣新舊兩套庫各管各的不會互相踩。安裝命令的大致形態(tài)如下# 安裝 OpenSSL 3.5.1假設 rpm 包已經(jīng)按 /usr/local/ssl 前綴打包 rpm -Uvh /path/to/openssl-3.5.1-1.el7.x86_64.rpm # 確認新動態(tài)庫與二進制在位 ls -l /usr/local/ssl/lib64/libcrypto.so.3 /usr/local/ssl/bin/openssl version說明/usr/local/ssl 是源碼編譯時 --prefix 的常見值如果你的 rpm 包不是這個路徑以rpm -ql openssl為準。之所以強調(diào)路徑是因為很多網(wǎng)上的“一鍵升級”rpm 包會把新庫直接裝進 /usr/lib64然后軟鏈接覆蓋成 libcrypto.so.3那種包安裝后系統(tǒng)立刻出現(xiàn)“yum 壞了、curl 壞了”的現(xiàn)象。所以在安裝前一定要檢查文件清單確認新 OpenSSL 沒有覆蓋系統(tǒng)庫。檢查命令是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不覆蓋系統(tǒng)舊配置 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 等內(nèi)容手動遷移到新配置里不能指望 rpm 自動合并。OpenSSH 從 8.x 開始默認算法持續(xù)收窄舊配置里的一些 AllowTcpForwarding、UseDNS 寫法雖然還在但語義可能有變化直接硬覆蓋進新配置可能讓 sshd 拒絕啟動。3.2 加固sshd_config協(xié)議、密鑰、算法、登錄策略一次配齊升級后的默認 sshd_config 通常已經(jīng)比舊版安全但距離等保和漏掃要求還差幾步。我習慣把加固項單獨寫到 /etc/ssh/sshd_config.d/hardening.conf而不是直接改主配置這樣以后再來一輪安全整改時只需要替換這一個文件。前提是主配置里要有Include /etc/ssh/sshd_config.d/*.conf一行CentOS 7.9 的默認配置已經(jīng)有這行了但如果你手工改過主配置需要確認一下。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 # 登錄策略公鑰認證優(yōu)先禁止空密碼 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 # 轉(zhuǎn)發(fā)控制除非確有必要全關 AllowTcpForwarding no AllowAgentForwarding no X11Forwarding no EOF參數(shù)說明PermitRootLogin 我這里寫的是 prohibit-password意思是 root 允許登錄但只能通過密鑰密碼完全不能進。如果你是內(nèi)部跳板機加上嚴格 ACL可以再收緊成 no。MaxAuthTries 3 和 LoginGraceTime 30 是掃描器判定暴力破解防護是否到位的兩個關鍵項。ClientAliveInterval 300 配合 ClientAliveCountMax 2能在客戶端“假死”時自動斷開連接避免系統(tǒng)里掛一堆空閑 sshd 進程。很多人在 vscode 里設置“連接 ssh 遠程服務器后十分鐘不用就斷線”其實就是服務端這兩個值沒配對到預期效果。算法這一排很容易引發(fā)“配了強算法結(jié)果連不上”的爭議。KexAlgorithms 只保留 curve25519 和 diffie-hellman-group16/18老客戶端如果只支持 group14協(xié)商就會失敗。Ciphers 去掉 aes128-cbc、3des-cbc是為了規(guī)避 Sweet32 這類針對 64 位塊大小密碼套件的碰撞攻擊。如果你環(huán)境里有老堡壘機或老網(wǎng)絡設備建議把 diffie-hellman-group14-sha256 也加回來作為管理網(wǎng)段的降級兜底。這個稍后在避坑部分詳細說。3.3 端口與SELinux改端口不是改一行配置的事升級到 10.0p1 后把 SSH 端口從 22 改為高位端口是常見的加固動作能降低被批量掃描的概率。但只改 sshd_config 里的 Port 是不夠的至少要同步處理三件事sshd_config 的監(jiān)聽端口、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參數(shù)說明semanage 來自 policycoreutils-python 包CentOS 7.9 默認可能沒裝缺的話先yum install -y policycoreutils-python。改完端口后要同時檢查云控制臺的安全組、內(nèi)網(wǎng)的 iptables 規(guī)則否則本地放行了云上沒放行一樣連不上。改端口還會影響已有的 ssh 批量登錄任務和 git remote 配置所有地方都要同步更新端口號。否則會出現(xiàn)“ssh 認證失敗 git 突然開始報錯”這種看起來像密鑰壞了、實際是端口沒改的烏龍。4. 升級后驗證清單服務可起、算法生效、遠程能連4.1 服務與端口驗證systemctl 和 ssh -V 雙確認升級完不能只看 rpm -qa 里有新版本就認為成功必須驗證 sshd 能持續(xù)運行。我的順序是先跑配置語法檢查再在前臺用 debug 模式啟動一兩次最后才交給 systemd 重啟。注意新版 sshd 的-t只能檢查語法檢查不了 SELinux 上下文和密鑰權(quán)限這些要在服務真正啟動時才暴露。# 配置語法檢查 /usr/sbin/sshd -t # 前臺 debug 模式看到監(jiān)聽端口和 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需要再執(zhí)行l(wèi)dd /usr/sbin/sshd | grep ssl確認。這是升級后最容易被忽略的“版本顯示已到位實際沒生效”問題。4.2 算法協(xié)商驗證用 ssh -vvv 看Kex和Ciphers配置了強算法后最擔心的不是配置本身而是“配置了但沒被讀取”。驗證算法是否生效我喜歡用另一臺機器發(fā)起一次 ssh -vvv直接看協(xié)商過程里最終選中的密鑰交換、哈希和加密算法。命令如下# 在另一臺機器上執(zhí)行觀察協(xié)商中實際使用的算法 ssh -vvv -p 22022 root目標機器 21 | grep -E KEX|host key|kex_parse|Ciphers|MACsgrep 輸出里如果有你配置里沒出現(xiàn)的算法說明 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這三個查詢命令可以用它直接列出當前二進制支持的算法全集。這個全集比配置里列出的要多屬于正?，F(xiàn)象不用擔心。升級后如果機器上還跑著 nginx、nacos 這類需要配置 ssl 證書的中間件也要順手檢查一遍它們的 SSL 庫鏈接特別是新版本 OpenSSL 的證書校驗策略和舊版有差異可能出現(xiàn)“openssl 升級后 ssl 連接錯誤”的情況。4.3 重啟不掉線的技巧tmux 安全會話升級和重啟 sshd 最怕的是當前連接斷掉。實際上重啟 sshd 通常不會切斷已有連接因為舊進程會繼續(xù)服務已建立的會話但如果你同時改了端口、禁用了密碼登錄、重建了 host key當前連接也可能被波及。我的鐵律是所有修改 sshd 的步驟都放在 tmux 會話里執(zhí)行并且提前把備用密鑰放到另一臺機器上。# 當前連接里開一個 tmux 會話 tmux new -s ssh_upgrade # 如果連接意外斷開重新登錄后在任意終端恢復會話 tmux attach -t ssh_upgrade提示在使用 tmux 的基礎上還要確保手里至少有兩把能登錄的密鑰一把留在本地一把放到內(nèi)網(wǎng)跳板機或另一臺管理機。血淚教訓是在 hardening.conf 里把 PasswordAuthentication 設為 no 后突然發(fā)現(xiàn)自己唯一的私鑰權(quán)限不對密碼登錄又被禁用整臺機器只?？刂婆_一條路。5. 避坑升級OpenSSH時最常見的5個翻車現(xiàn)場5.1 升級 OpenSSL 后 yum 報錯libcrypto.so.10 不見了現(xiàn)象執(zhí)行 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并在安裝時替換或刪除了系統(tǒng)原有的 libcrypto.so.10 軟鏈接。CentOS 7.9 的 python、yum、curl 都鏈接舊庫所以整個基礎工具鏈立刻崩掉。更麻煩的是有些 rpm 包為了“兼容”安裝時直接覆蓋了系統(tǒng)軟鏈接讓你以為新舊共存其實舊的已經(jīng)沒了。解決如果新 OpenSSL 已經(jīng)污染了系統(tǒng)庫先用備份的舊 rpm 包強制恢復rpm -Uvh --replacepkgs --oldpackage /root/ssh_upgrade_backup/rpm/openssl-1.0.2k-*.rpm這里的關鍵參數(shù)是 --oldpackage允許用舊版本覆蓋新版本否則 rpm 會提示“已安裝更新版本”?；謴秃蟠_認openssl version回到 1.0.2k再重新把新 OpenSSL 以獨立目錄方式安裝。正確的安裝方式可以避免這個坑裝新包前用rpm -qpl檢查文件路徑確認新庫進入 /usr/local/ssl 而不是 /usr/lib64。如果機器上還跑著 mysql、dify 這類依賴 SSL 的服務升級后也要重點看它們鏈接的是哪個 libssl避免“mysql ssl 連接錯誤”這類連鎖故障。5.2 sshd 重啟后連接被拒絕主機密鑰權(quán)限與上下文現(xiàn)象systemctl restart sshd 狀態(tài)顯示 active但遠程連接時報no hostkeys available或者 ssh 客戶端提示 host key verification failed。用 sshd -t 檢查卻沒有輸出錯誤。原因舊主機密鑰從備份目錄恢復后權(quán)限可能變成了 0644或者 SELinux 上下文因為文件被移動而丟失。新版 OpenSSH 對 host key 文件權(quán)限檢查很嚴格要求 0600 且屬主是 root。SELinux 開啟時文件上下文必須是 sshd_key_t否則 sshd 在讀取階段就會被拒絕。解決恢復密鑰后統(tǒng)一刷權(quán)限和上下文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 密碼登錄被禁但密鑰又沒配對血淚教訓現(xiàn)象加固配置里寫了 PasswordAuthentication no重載后密碼登錄全部失敗密鑰登錄也失敗提示 Permission denied。用 ssh -vvv 能看到服務端接受了公鑰但客戶端始終過不了認證。原因多數(shù)情況下是客戶端私鑰權(quán)限太寬松。OpenSSH 7.8 之后開始檢查私鑰文件權(quán)限如果 ~/.ssh/id_rsa 是 0644會直接拒絕使用。服務端配置沒問題但客戶端私鑰不合法導致認證中斷。還有一種可能known_hosts 里的舊 host key 和新 key 不匹配客戶端在確認新 host key 時中斷看起來像認證失敗。解決在客戶端上先修正私鑰權(quán)限再清理舊 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 這類批量登錄工具也要同步檢查它們使用的私鑰路徑和權(quán)限。這個坑在升級后“ssh 認證失敗 git”的場景里尤其常見——git 操作看著是密鑰失效實際是私鑰權(quán)限或 host key 不匹配。5.4 配置了強算法卻發(fā)現(xiàn)客戶端連不上兼容性邊界現(xiàn)象KexAlgorithms 和 Ciphers 收緊后老客戶端直接報no matching key exchange method found或no matching cipher found。原因Xshell、PuTTY 舊版本以及老系統(tǒng)的 OpenSSH 7.3 等只支持 diffie-hellman-group14-sha1、aes128-cbc 這類已經(jīng)被禁用的弱算法。安全加固把弱算法全禁掉老工具自然協(xié)商失敗。解決從安全角度可以保留一組降級算法但限制來源網(wǎng)段。用 Match Address 指令把弱算法只開放給管理網(wǎng)段這樣全局不暴露弱算法內(nèi)網(wǎng)老工具又能正常連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參數(shù)說明行首的 號表示在全局配置基礎上追加而不是替換。如果你的合規(guī)要求是全段都不能出現(xiàn)弱算法就只能強制客戶端升級或者用 ssh -o KexAlgorithms... 在客戶端手工指定算法。這個坑提醒我們?nèi)魏渭庸塘６榷家劝选澳苓B”作為第一優(yōu)先級再談強弱。5.5 SELinux 攔截新端口sshd 起不來卻看不到報錯現(xiàn)象把端口改到 22022 后systemctl status sshd 顯示 active但客戶端始終連接不上。journalctl -u sshd 也沒有明顯錯誤。原因SELinux 強制模式下sshd 只被允許監(jiān)聽帶有 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。這是為了修一條規(guī)則把整堵墻拆了不推薦。正確做法是安裝 policycoreutils-python只補加一條端口規(guī)則。改完端口后還要記得在云安全組里同步放行否則本地規(guī)則加好了遠端云平臺沒放行依然連不上。6. 收尾做一個一鍵回滾腳本把升級失敗的成本降到最低升級到這里基本完成但真正讓運維敢在生產(chǎn)環(huán)境執(zhí)行的是留一條退路。我習慣在腳本最后自動生成一個 rollback.sh內(nèi)容不復雜但能救急備份目錄里留著一整套舊 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 恢復失敗請從原始介質(zhì)補齊舊包 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 規(guī)則 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 端口未監(jiān)聽請手動檢查 EOF chmod x /root/ssh_upgrade_backup/rollback.sh這個腳本里最關鍵的是 --oldpackage它允許舊版本 rpm 覆蓋新版本否則 rpm 會拒絕降級。備份目錄里如果沒有完整保留舊 rpm 包回滾就是空話。我自己的習慣是每次升級完先檢查回滾腳本里的端口號是否匹配再把整個備份目錄壓縮成 tar 包扔到內(nèi)網(wǎng)獨立存儲上。真出事時我寧可多花五分鐘回滾也絕不現(xiàn)場去看“為什么 sshd 起不來”。這套流程走過幾次之后回滾腳本在我心里的優(yōu)先級早就超過了升級腳本本身。希望幫到你。本文還有配套的精品資源點擊獲取