簡介本資源面向 Rocky Linux 9.5 系統(tǒng)運維人員與安全加固實踐者針對舊版 OpenSSH 與 OpenSSL 存在的安全風(fēng)險提供一套可直接落地的升級加固方案幫助讀者在 x86_64 環(huán)境下完成 SSH 服務(wù)的高版本替換與安全配置。壓縮包共 6 個文件包含 5 個 rpm 安裝包與 1 個 sh 腳本涵蓋 openssh、openssh-clients、openssh-server 等核心組件及 chkconfig、initscripts 依賴包整體約 10.96MB腳本負(fù)責(zé)串聯(lián)升級流程rpm 包則用于替換系統(tǒng)自帶舊版本。資源描述中展示了升級后 ssh -V 輸出 OpenSSH_10.0p2 與 OpenSSL 3.5.0 的驗證結(jié)果并附有 sshd 服務(wù)運行狀態(tài)說明方案已在 Rocky Linux 9.5 上完成實測。目前已有 199 人學(xué)習(xí)適合需要快速完成 SSH 版本升級、減少手工編譯排錯成本的中高級運維人員參考也可作為內(nèi)網(wǎng)安全加固的腳本模板。1. 從一次 SSH 升級翻車說起這套 RPM 腳本到底解決什么問題上個月幫一個朋友處理一臺 Rocky Linux 9.5 的服務(wù)器OpenSSH 還停在系統(tǒng)自帶的 8.7 版本掃描報告里一堆中危項全指著它。他之前自己手動編譯升級過一次結(jié)果第二天 SSH 直接連不上只能跑機房掛 KVM 救回來。這種血淚經(jīng)驗在運維圈太常見了——源碼編譯 OpenSSH 看著簡單但 PAM 模塊路徑、sshd_config 權(quán)限、SELinux 上下文、systemd 單元文件任何一個環(huán)節(jié)對不上就是把自己關(guān)在門外的節(jié)奏。這套rockylinux9.5-ssh10.0p1-ssl3.5.0-rpm-x86-64升級加固腳本就是沖著這個場景來的。它把 OpenSSH 10.0p1 和 OpenSSL 3.5.0 打包成 RPM在 Rocky Linux 9.5 x86_64 上做原地升級同時附帶一套加固配置。適合兩類人一是手里有 Rocky 9.5 機器、被合規(guī)掃描追著跑的運維二是想學(xué) RPM 打包和 SSH 加固聯(lián)動邏輯的工程師。它不解決“從零編譯”的教學(xué)需求解決的是“別把自己鎖在門外”的落地問題。2. 拆開 RPM 包看門道OpenSSH 10.0p1 與 OpenSSL 3.5.0 的依賴鏈2.1 為什么選 RPM 而不是源碼編譯源碼編譯 OpenSSH 的經(jīng)典翻車點在于./configure時--with-ssl-dir指向的 OpenSSL 路徑和運行時ldd /usr/sbin/sshd實際加載的庫路徑經(jīng)常不一致。你編譯時用的是/usr/local/ssl/lib64但 sshd 啟動時LD_LIBRARY_PATH沒帶上它就去/lib64找系統(tǒng)自帶的 OpenSSL 1.1版本對不上直接段錯誤。更隱蔽的是 PAM編譯時--with-pam開了但pam.d/sshd文件沒同步更新認(rèn)證階段靜默失敗日志里只留一句PAM: Authentication failure排查半天。RPM 方案的核心優(yōu)勢是把依賴關(guān)系寫死在 spec 文件的Requires和Provides里。安裝時rpm -ivh或dnf localinstall會自動校驗 OpenSSL 版本、glibc 版本、PAM 庫版本不滿足直接拒絕安裝不會出現(xiàn)“裝完了才發(fā)現(xiàn)跑不起來”的情況。而且 RPM 的%post腳本可以自動處理sshd_config權(quán)限、生成 host key、重載 systemd這些手工步驟全被固化下來。2.2 包內(nèi)文件布局與關(guān)鍵路徑拿到 RPM 包后先別急著裝。用rpm -qlp看一眼文件清單心里有數(shù)再動手# 查看 RPM 包內(nèi)所有文件路徑不實際安裝 rpm -qlp openssh-10.0p1-ssl3.5.0.el9.x86_64.rpm | head -40 # 查看包的依賴聲明確認(rèn) OpenSSL 版本要求 rpm -qRp openssh-10.0p1-ssl3.5.0.el9.x86_64.rpm | grep -i ssl # 查看包的元信息版本、構(gòu)建時間、簽名 rpm -qip openssh-10.0p1-ssl3.5.0.el9.x86_64.rpm這里有個細(xì)節(jié)rpm -qRp輸出的依賴?yán)锶绻霈F(xiàn)libcrypto.so.3()(64bit)這種 soname 依賴說明包是動態(tài)鏈接到 OpenSSL 3.x 的。如果系統(tǒng)里還殘留 OpenSSL 1.1 的 compat 包dnf可能會嘗試同時滿足兩個版本導(dǎo)致沖突。常見做法是先dnf remove openssl-compat清理舊庫再裝新包。關(guān)鍵路徑對照表路徑作用升級后注意事項/usr/sbin/sshd主程序確認(rèn)ldd指向新 OpenSSL/etc/ssh/sshd_config服務(wù)端配置權(quán)限必須 600屬主 root/etc/ssh/ssh_config客戶端配置一般不動除非要禁弱算法/etc/pam.d/sshdPAM 認(rèn)證配置升級后檢查是否被覆蓋/usr/lib/systemd/system/sshd.servicesystemd 單元確認(rèn)ExecStart路徑正確/etc/ssh/ssh_host_*_key主機密鑰升級不會自動重建除非手動刪2.3 升級前的快照與回滾準(zhǔn)備RPM 升級雖然比源碼編譯可控但也不是沒有后悔藥。動手前先做三件事# 1. 備份當(dāng)前 sshd 配置和二進制 cp -a /etc/ssh /etc/ssh.bak.$(date %Y%m%d) cp -a /usr/sbin/sshd /usr/sbin/sshd.bak # 2. 記錄當(dāng)前版本和依賴關(guān)系 rpm -qa | grep -E openssh|openssl /root/pkg-before.txt ldd /usr/sbin/sshd /root/ldd-before.txt # 3. 確認(rèn)當(dāng)前 SSH 會話不會被中斷關(guān)鍵 # 不要在生產(chǎn)環(huán)境直接重啟 sshd先用新端口起一個測試實例 /usr/sbin/sshd -f /etc/ssh/sshd_config -p 2222 -t第三步的-t是語法檢查-p 2222是臨時端口。如果語法檢查通過再用-p 2222實際啟動一個測試實例從另一個終端連上去驗證確認(rèn)沒問題再替換主服務(wù)。這個習(xí)慣我每次升級 SSH 都強制走一遍能擋掉八成“改完連不上”的事故。3. 加固配置落地從 sshd_config 到 PAM 的逐項調(diào)優(yōu)3.1 sshd_config 核心加固項與參數(shù)含義OpenSSH 10.0p1 的默認(rèn)配置比 8.x 嚴(yán)格了不少但離合規(guī)要求還有距離。下面這份配置是我在多個 Rocky 9.5 環(huán)境里驗證過的直接抄# /etc/ssh/sshd_config 關(guān)鍵加固段 Protocol 2 Port 22 AddressFamily inet ListenAddress 0.0.0.0 # 認(rèn)證策略 PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no UsePAM yes # 算法限制只保留強加密套件 KexAlgorithms curve25519-sha256,curve25519-sha256libssh.org,diffie-hellman-group16-sha512 Ciphers chacha20-poly1305openssh.com,aes256-gcmopenssh.com,aes128-gcmopenssh.com MACs hmac-sha2-512-etmopenssh.com,hmac-sha2-256-etmopenssh.com # 會話限制 LoginGraceTime 30 MaxAuthTries 3 MaxSessions 5 ClientAliveInterval 300 ClientAliveCountMax 2 # 日志與轉(zhuǎn)發(fā) SyslogFacility AUTH LogLevel VERBOSE X11Forwarding no AllowAgentForwarding no AllowTcpForwarding no逐項說明幾個容易踩坑的PermitRootLogin no是硬要求但改之前確認(rèn)你有普通用戶能 sudo否則重啟后 root 登不上、普通用戶也沒配就真進不去了。PasswordAuthentication no意味著必須提前把公鑰塞進~/.ssh/authorized_keys而且權(quán)限必須是 700目錄和 600文件屬主是用戶自己否則 sshd 會靜默拒絕。KexAlgorithms里我保留了diffie-hellman-group16-sha512因為有些老舊的網(wǎng)絡(luò)設(shè)備只支持這個。如果你的環(huán)境全是新客戶端可以只留 curve25519。MACs里的-etm后綴是 encrypt-then-MAC比傳統(tǒng) MAC 更安全但極老的客戶端可能不支持。3.2 PAM 與 SELinux 的聯(lián)動檢查改完sshd_config別急著重啟先過一遍 PAM 和 SELinux# 檢查 PAM 配置是否引用了正確的模塊路徑 grep -E pam_unix|pam_sss|pam_faillock /etc/pam.d/sshd # 確認(rèn) SELinux 上下文正確 ls -Z /usr/sbin/sshd /etc/ssh/sshd_config # 期望輸出類似system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd # 如果上下文不對手動修復(fù) restorecon -Rv /etc/ssh /usr/sbin/sshd # 檢查 SELinux 是否阻止了 sshd 綁定端口 ausearch -m avc -ts recent | grep sshdRocky 9.5 默認(rèn)開 SELinux enforcing。RPM 安裝時%post腳本通常會調(diào)restorecon但如果你之前手動改過/etc/ssh下的文件上下文可能被破壞。ls -Z看到default_t而不是sshd_exec_tsshd 啟動就會被拒。ausearch那條命令是排查 SELinux 拒絕的萬能鑰匙任何“配置都對但就是起不來”的情況先看這里。3.3 用 sshd -T 做配置有效性驗證OpenSSH 10.0p1 的sshd -T比老版本輸出更詳細(xì)能直接看到生效的最終配置# 以測試模式輸出最終生效配置不實際啟動服務(wù) /usr/sbin/sshd -T -f /etc/ssh/sshd_config | grep -E permitrootlogin|passwordauth|kexalgorithms|ciphers|macs # 如果配置文件有語法錯誤-t 會直接報錯并指出行號 /usr/sbin/sshd -t -f /etc/ssh/sshd_config-T的好處是它會把 include 的文件、默認(rèn)值全部展開你看到的就是 sshd 實際用的。有時候你在sshd_config里寫了PasswordAuthentication no但/etc/ssh/sshd_config.d/下有個 50-cloud-init.conf 又把它改回 yes-T一跑就露餡。Rocky 9.5 默認(rèn)會加載sshd_config.d/*.conf這個目錄里的文件優(yōu)先級比主配置高升級后務(wù)必檢查。4. 避坑排查升級 SSH 時最容易翻車的五個點4.1 現(xiàn)象重啟 sshd 后當(dāng)前會話斷開新連接被拒原因sshd_config里L(fēng)istenAddress或Port改了但防火墻沒放行新端口或者AllowUsers/AllowGroups限制了來源而當(dāng)前用戶不在列表里。解決永遠(yuǎn)不要直接systemctl restart sshd。先用sshd -p 2222 -t測試再sshd -p 2222起臨時實例從另一個終端連 2222 驗證。確認(rèn)無誤后用systemctl reload sshd不是 restart平滑加載。如果已經(jīng)鎖死只能通過 KVM 或串口進單用戶模式改回來。4.2 現(xiàn)象公鑰認(rèn)證失敗日志顯示 “Authentication refused: bad ownership or modes”原因~/.ssh或authorized_keys權(quán)限不對。sshd 對權(quán)限極其敏感目錄必須是 700文件必須是 600且屬主必須是登錄用戶本人不能是 root 或其他用戶。解決chmod 700 /home/username/.ssh chmod 600 /home/username/.ssh/authorized_keys chown -R username:username /home/username/.ssh # 同時檢查家目錄本身不能是 group-writable chmod g-w /home/username4.3 現(xiàn)象升級后 root 無法登錄普通用戶 sudo 也報錯原因PermitRootLogin no生效了但普通用戶的 sudo 權(quán)限沒配好或者 PAM 的pam_faillock模塊因為多次失敗把賬戶鎖了。解決升級前務(wù)必確認(rèn)至少有一個普通用戶能sudo su -。如果已經(jīng)被鎖進單用戶模式后faillock --user username --reset解鎖。PAM 配置里pam_faillock的deny3和unlock_time900是默認(rèn)值可以根據(jù)需要調(diào)整。4.4 現(xiàn)象sshd 啟動報 “error while loading shared libraries: libcrypto.so.3”原因OpenSSL 3.5.0 的 RPM 沒裝或者裝了但ldconfig緩存沒更新sshd 找不到新庫。解決# 確認(rèn) OpenSSL 3.5.0 已安裝 rpm -qa | grep openssl # 更新動態(tài)鏈接器緩存 ldconfig -v | grep libcrypto # 如果還是找不到手動指定庫路徑測試 LD_LIBRARY_PATH/usr/local/ssl/lib64 ldd /usr/sbin/sshd | grep crypto4.5 現(xiàn)象SELinux 導(dǎo)致 sshd 無法綁定端口或讀取 host key原因RPM 安裝時%post腳本沒執(zhí)行restorecon或者手動拷貝文件時丟了上下文。解決# 查看拒絕日志 ausearch -m avc -ts today | grep sshd # 恢復(fù)默認(rèn)上下文 restorecon -Rv /etc/ssh /usr/sbin/sshd /var/empty/sshd # 如果還不行臨時設(shè)為 permissive 確認(rèn)是否是 SELinux 問題 setenforce 0 # 確認(rèn)后記得改回 enforcing setenforce 15. 進階技巧用 RPM 腳本做批量加固與版本回滾5.1 把加固配置寫進 RPM 的 %post 腳本如果你要在多臺機器上批量部署手動改sshd_config太慢?？梢园鸭庸踢壿媽戇M RPM 的%post段安裝時自動執(zhí)行# 在 spec 文件的 %post 段中加入 %post # 備份原配置 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.rpmsave # 用 sed 批量替換關(guān)鍵項 sed -i s/^#*PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config sed -i s/^#*PasswordAuthentication.*/PasswordAuthentication no/ /etc/ssh/sshd_config sed -i s/^#*MaxAuthTries.*/MaxAuthTries 3/ /etc/ssh/sshd_config # 確保權(quán)限正確 chmod 600 /etc/ssh/sshd_config chown root:root /etc/ssh/sshd_config # 語法檢查失敗則回滾 if ! /usr/sbin/sshd -t -f /etc/ssh/sshd_config; then cp /etc/ssh/sshd_config.rpmsave /etc/ssh/sshd_config echo sshd_config syntax error, rolled back 2 exit 1 fi # 平滑重載 systemctl reload sshd || systemctl restart sshd這段腳本的關(guān)鍵在于sshd -t失敗時自動回滾。很多批量升級事故就是因為配置寫錯了但沒人發(fā)現(xiàn)直到重啟后所有機器都連不上。加上這個判斷至少能保證配置語法層面不出問題。5.2 版本回滾用 dnf history 撤銷升級RPM 體系最大的好處就是有后悔藥。如果升級后發(fā)現(xiàn)兼容性問題可以回滾# 查看 dnf 操作歷史找到升級那一步的 ID dnf history list | head -20 # 假設(shè)升級操作 ID 是 15回滾到之前的狀態(tài) dnf history undo 15 # 如果 dnf history 不夠用直接降級 RPM 包 rpm -Uvh --oldpackage openssh-8.7p1-38.el9.x86_64.rpm # 恢復(fù)備份的配置 cp -a /etc/ssh.bak.20250101/* /etc/ssh/ systemctl restart sshddnf history undo會自動處理依賴關(guān)系比手動rpm -Uvh --oldpackage更干凈。但注意如果升級后已經(jīng)改了配置文件undo 不會恢復(fù)配置需要手動從備份還原。5.3 驗證加固效果的三個命令升級加固完別只看systemctl status顯示 running 就完事。用這三個命令做最終驗證# 1. 確認(rèn)實際生效的算法列表 ssh -vvv localhost 21 | grep -E kex: algorithm|ciphers: |mac: # 2. 確認(rèn)版本號 ssh -V # 3. 用 nmap 從外部掃描確認(rèn)沒有弱算法暴露 nmap --script ssh2-enum-algos -p 22 target_ip第一條命令的-vvv會打印握手細(xì)節(jié)你能看到實際協(xié)商的 kex、cipher、mac 是不是你配置里指定的那些。如果出現(xiàn)了diffie-hellman-group14-sha1這種弱算法說明配置沒生效大概率是sshd_config.d/下有文件覆蓋了。第三條用 nmap 從外部視角看更接近掃描器的判斷邏輯。從那以后我每次升級 SSH都強制走一遍“備份 → 臨時端口測試 → sshd -T 驗證 → 外部掃描確認(rèn)”的流程再也沒被鎖在門外過。希望幫到你。本文還有配套的精品資源點擊獲取