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