簡介本資源面向 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腳本負責(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文件沒同步更新認證階段靜默失敗日志里只留一句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 # 查看包的依賴聲明確認 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這里有個細節(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主程序確認ldd指向新 OpenSSL/etc/ssh/sshd_config服務(wù)端配置權(quán)限必須 600屬主 root/etc/ssh/ssh_config客戶端配置一般不動除非要禁弱算法/etc/pam.d/sshdPAM 認證配置升級后檢查是否被覆蓋/usr/lib/systemd/system/sshd.servicesystemd 單元確認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. 確認當(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實際啟動一個測試實例從另一個終端連上去驗證確認沒問題再替換主服務(wù)。這個習(xí)慣我每次升級 SSH 都強制走一遍能擋掉八成“改完連不上”的事故。3. 加固配置落地從 sshd_config 到 PAM 的逐項調(diào)優(yōu)3.1 sshd_config 核心加固項與參數(shù)含義OpenSSH 10.0p1 的默認配置比 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 # 認證策略 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是硬要求但改之前確認你有普通用戶能 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 # 確認 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 默認開 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比老版本輸出更詳細能直接看到生效的最終配置# 以測試模式輸出最終生效配置不實際啟動服務(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 的文件、默認值全部展開你看到的就是 sshd 實際用的。有時候你在sshd_config里寫了PasswordAuthentication no但/etc/ssh/sshd_config.d/下有個 50-cloud-init.conf 又把它改回 yes-T一跑就露餡。Rocky 9.5 默認會加載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)前用戶不在列表里。解決永遠不要直接systemctl restart sshd。先用sshd -p 2222 -t測試再sshd -p 2222起臨時實例從另一個終端連 2222 驗證。確認無誤后用systemctl reload sshd不是 restart平滑加載。如果已經(jīng)鎖死只能通過 KVM 或串口進單用戶模式改回來。4.2 現(xià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ù)必確認至少有一個普通用戶能sudo su -。如果已經(jīng)被鎖進單用戶模式后faillock --user username --reset解鎖。PAM 配置里pam_faillock的deny3和unlock_time900是默認值可以根據(jù)需要調(diào)整。4.4 現(xiàn)象sshd 啟動報 “error while loading shared libraries: libcrypto.so.3”原因OpenSSL 3.5.0 的 RPM 沒裝或者裝了但ldconfig緩存沒更新sshd 找不到新庫。解決# 確認 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ù)默認上下文 restorecon -Rv /etc/ssh /usr/sbin/sshd /var/empty/sshd # 如果還不行臨時設(shè)為 permissive 確認是否是 SELinux 問題 setenforce 0 # 確認后記得改回 enforcing setenforce 15. 進階技巧用 RPM 腳本做批量加固與版本回滾5.1 把加固配置寫進 RPM 的 %post 腳本如果你要在多臺機器上批量部署手動改sshd_config太慢。可以把加固邏輯寫進 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. 確認實際生效的算法列表 ssh -vvv localhost 21 | grep -E kex: algorithm|ciphers: |mac: # 2. 確認版本號 ssh -V # 3. 用 nmap 從外部掃描確認沒有弱算法暴露 nmap --script ssh2-enum-algos -p 22 target_ip第一條命令的-vvv會打印握手細節(jié)你能看到實際協(xié)商的 kex、cipher、mac 是不是你配置里指定的那些。如果出現(xiàn)了diffie-hellman-group14-sha1這種弱算法說明配置沒生效大概率是sshd_config.d/下有文件覆蓋了。第三條用 nmap 從外部視角看更接近掃描器的判斷邏輯。從那以后我每次升級 SSH都強制走一遍“備份 → 臨時端口測試 → sshd -T 驗證 → 外部掃描確認”的流程再也沒被鎖在門外過。希望幫到你。本文還有配套的精品資源點擊獲取