麒麟与 openEuler 服务器在运维上有大量共同基础，但不能把两者当成同一个发行版。产品版本、补丁级别和 CPU 架构的差异，会直接影响软件仓库、驱动、网络管理与安全策略。银河麒麟高级服务器系统还可能启用厂商特定安全机制；openEuler 则要依据所用 LTS 版本及更新文档来维护。直接复制一份通用 Linux 加固脚本，常常会在远程连接、业务依赖或安全审计上引发意外。
本文面向采用 systemd、RPM 软件管理和 NetworkManager 的常见服务器环境，围绕网络、SSH、服务和安全加固建立可验证流程。麒麟桌面版、旧服务器版本、其他同名产品和使用不同网络栈的定制系统，应先核对实际管理组件再选择对应分支。本文不会假定每台机器都有 dnf、SELinux 或特定厂商命令，工具支持以本机帮助、发行版文档和批准介质为准。
所有地址、账户、服务名和配置都是教学示例，命令未在读者服务器执行。文中使用保留示例网段和文档域名，部署时替换为真实值。管理网卡变更和 SSH 加固必须保留控制台或带外入口，现有会话留到新连接验证成功以后再退出。安全策略不是追求设置越多越好，而是明确谁可以连接、谁可以提升权限、服务需要访问什么，以及每个改变能否回退。
建立发行版、架构与管理组件基线
排障开始先确认系统身份。uname 显示内核，os-release 显示发行版，RPM 查询显示软件包，它们回答的是不同问题。厂商可能回补安全修复而不改变上游主版本，因此不能只凭版本字符串判断漏洞是否未修复。国产服务器还常见 ARM、海光、飞腾和其他平台，二进制与驱动支持必须分别核对。
读取发行版、内核与体系架构，确定后续命令适用范围。系统名称相近不等于软件源互通，尤其不要把桌面系统仓库或其他发行版仓库加到关键业务服务器上解决一个依赖错误。
cat /etc/os-release
uname -r
uname -m
将版本和补丁级别保存进资产记录。原厂支持合同和认证范围也可能与具体版本相关，维护时应清楚目标是社区 openEuler 还是厂商产品。
查询包管理工具和关键管理软件版本，识别系统实际能力。旧版本可能只有 yum，新版以 dnf 为主；命令存在只代表工具可用，配置方式仍取决于服务是否负责当前网络或安全策略。
command -v dnf yum rpm nmcli firewall-cmd
rpm -q systemd NetworkManager openssh-server firewalld
缺少某个软件包不等于系统异常，可能只是采用了替代组件。不要为了执行教程同时启用多套网络管理服务，它们可能争夺同一接口和 DNS 配置。
读取硬件与 CPU 视图，确认虚拟机、NUMA 和资源范围。数据库和 GPU 服务器的性能问题往往与 CPU 绑定及内存位置有关，但本节只建立基线，不立即套用通用 sysctl 调优。
lscpu
free -h
systemd-detect-virt || true
内存空闲少不必然是泄漏，Linux 会使用缓存。先区分可回收缓存、匿名内存和服务限制，再决定是否需要容量扩展或进程诊断。
查看主机名、时间与启动时间，保证后续日志能关联。时间偏差会影响证书、认证和分布式数据库事件排序；主机名变化还可能影响监控标签和业务发现，应纳入正式变更。
hostnamectl
timedatectl
uptime -s
不要把手工改时间当长期同步方案。确定时间源、时区和同步状态后再分析认证失败，避免把过期证书或日志时间错位误判成网络故障。
检查系统当前运行状态及失败服务，先识别整体异常。服务器可以仍然接受 SSH，但某些基础服务已经失败；忽视这些状态会让后面的应用排障出现反复和间接错误。
systemctl is-system-running
systemctl --failed --no-pager
degraded 表示存在失败单元，不一定整机不可用。逐项判断影响范围，不要对所有失败服务批量 restart，某些单元可能需要修配置或恢复挂载。
核对磁盘、inode 与挂载状态，排除配置无法写入和日志丢失。空间充足但 inode 耗尽同样会导致服务创建文件失败；只查根目录容量可能漏掉独立日志、数据或 home 分区。
df -hT
df -i
findmnt
发现只读挂载先查文件系统和内核错误，不直接强制 remount 继续写。数据库和审计数据所在卷应保护现场，避免无依据的修复造成更大损坏。
创建受限的维护记录目录，保存每次操作前的基线。这里不把整个 /etc 公开打包，配置可能包含秘密；精确备份本次要改的文件，并记录权限与时间。
umask 077
OPS_DIR="$PWD/ops-change-$(date +%Y%m%d%H%M%S)"
mkdir -p "$OPS_DIR"
{ cat /etc/os-release; uname -r; date -Is; } > "$OPS_DIR/baseline.txt"
变量需要在后续 shell 中保持，重新登录后用实际目录替换。可回退的维护来自明确原状态，不来自“再改回大概一样”的记忆。
网络排障，从接口到应用分层
网络正常不是一个单一状态。接口有链路、地址正确、路由正确、DNS 可解析、目标端口可建立连接、TLS 验证通过以及应用返回正常，必须分别检查。ping 只测试一种流量，能 ping 通并不证明 HTTPS 可用，ping 不通也可能只是 ICMP 被限制。
查看接口行政状态、链路和地址，确认业务实际走哪张网卡。接口名称随硬件和系统策略变化，不要假设一定叫 eth0；多网卡服务器应区分管理、业务和存储网络。
ip -br link
ip -br address
UP 和有 carrier 不是同一个概念。接口启用却无链路时查线缆、交换机和驱动，地址缺失再查网络连接定义，不先修改默认路由。
读取路由与指定目的地的实际选路，判断源地址和出口。多网卡机器可能有多个默认路由，目标连接走错接口会导致超时；路由表看似合理也需要用 get 验证实际选择。
ip route show
ip route get 192.0.2.10
ip rule show
返回的 src 和 dev 应与网络设计一致。策略路由可能改变默认表行为，不能只删掉第二条 default 就宣布修复，应先理解管理与业务流量分离要求。
检查 NetworkManager 的设备和活动连接，区分接口与连接配置。一个网卡可以对应多个保存的 profile，而只有某个 profile 正在生效；修改错 profile 会出现配置文件正确却网络仍旧的现象。
nmcli device status
nmcli connection show --active
nmcli -f GENERAL,IP4,IP6 device show eno1
eno1 是示例设备，实际名称以本机为准。unmanaged 状态可能由其他管理器或配置负责，先确认职责，不能直接强制接管正在工作的管理网络。
检查 DNS 来源与主机解析路径，区分 nameserver 配置和实际解析结果。resolv.conf 可能由 NetworkManager 或其他组件生成，手工覆盖后也可能被下一次连接激活改回。
ls -l /etc/resolv.conf
cat /etc/resolv.conf
getent ahosts example.com
getent 使用系统解析规则，包括 hosts 和 NSS。与 dig 结果不同可能来自解析路径差异，不能只看某台 DNS 服务器正常就判断应用解析一定正常。
直接查询指定 DNS 服务器，验证服务器能否返回目标记录。dig 来自相应工具包，未安装时通过批准仓库获取；这一步测试 DNS，不等于 HTTPS 或业务地址可以连通。
dig @192.0.2.53 example.com A +time=2 +tries=1
dig @192.0.2.53 example.com AAAA +time=2 +tries=1
分别看响应状态、答案和延迟。NXDOMAIN、超时和空 AAAA 结果语义不同，保留完整输出可以防止把正常无 IPv6 记录误当 DNS 故障。
用 TCP 与 TLS 测试替代单独 ping 结论，观察失败发生阶段。curl 的详细输出会区分解析、连接和握手；连接超时与证书不受信任需要不同修复，不应统一关闭验证。
curl --verbose --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null
测试域名换成真实服务，分享输出前脱敏内部地址和代理信息。若有白名单，确认放行的是目标域名对应出口和端口，而不是只放行 ICMP。
用固定地址保留 TLS 主机名，分离 DNS 与连接问题。示例地址属于文档网段，执行前替换真实服务地址；直接访问 https IP 会改变证书匹配和 SNI，不能作为同等对照。
curl --verbose --resolve example.com:443:192.0.2.10 --connect-timeout 5 https://example.com/ -o /dev/null
固定地址成功而正常域名失败，支持 DNS 或解析路径问题的假设。仍需核对负载均衡地址、IPv4/IPv6 和代理，不把一次对照当全部网络已经修复。
配置 NetworkManager，保留可回退路径
持久网络变更应该交给实际负责该接口的组件。采用 NetworkManager 时优先修改连接 profile，不混合手工 ip 命令与旧 network-scripts 服务同时管理。远程修改管理网卡可能切断会话，应准备控制台，并在支持的版本使用 checkpoint，让未确认的变更自动回退。
读取目标连接的完整配置，记录原地址、网关、DNS 和自动连接策略。连接名可能包含空格，始终用引号；尽量使用 UUID 定位，防止两个相同显示名称的 profile 被误操作。
nmcli connection show "mgmt-old"
nmcli -g connection.uuid connection show "mgmt-old"
网络信息可能包含认证秘密，默认不要加 show-secrets。后续改动应有明确预期，只变更本次必要字段，不顺便改变 MTU、IPv6 和路由策略。
克隆原连接作为回退 profile，保存原定义而不删除。clone 并非文件系统级完整备份，但适合保留 NetworkManager 连接参数；原连接和克隆不要同时设置成会争夺接口的自动连接。
sudo nmcli connection clone "mgmt-old" "mgmt-before-change"
sudo nmcli connection modify "mgmt-before-change" connection.autoconnect no
记录克隆 UUID 与原 UUID。确认回退可以从控制台执行，避免只保存一份网络配置却在断网后无法远程激活它。
创建新的静态管理 profile，先保存不立即激活。下面使用文档示例网段和 DNS，需要替换为分配地址；新 profile 自动连接关闭，防止重启后未经验证成为默认。
sudo nmcli connection add type ethernet ifname eno1 con-name mgmt-static \
ipv4.method manual ipv4.addresses 192.0.2.20/24 \
ipv4.gateway 192.0.2.1 ipv4.dns "192.0.2.53 192.0.2.54" \
connection.autoconnect no
地址冲突、网关位置和防火墙来源都要提前核对。管理地址改变后，监控、堡垒机、证书和资产系统可能需要同步更新，不只关注本机能否访问外网。
检查是否支持 checkpoint，并用带回退窗口的激活命令测试新连接。该语法以本机 nmcli 帮助为准，不支持时采用控制台维护；完成后工具要求确认，未确认会在窗口结束回退。
nmcli device checkpoint --help
sudo nmcli device checkpoint --timeout 120 eno1 -- nmcli connection up "mgmt-static"
确认前从另一个终端验证新 SSH、网关、DNS 和业务访问。会话暂时不断并不代表新地址可用，必须建立新的连接才有资格确认成功。
只修改 DNS 时在活动 profile 中声明服务器和自动 DNS 策略。下面示例针对确实采用固定 DNS 的设计，不是要求所有 DHCP 服务器忽略自动 DNS；变更后按支持情况 reapply。
sudo nmcli connection modify "mgmt-static" ipv4.dns "192.0.2.53 192.0.2.54" ipv4.ignore-auto-dns yes
sudo nmcli device reapply eno1
某些字段不能在线重应用，需在维护窗口重新激活。读取实际 resolv.conf 与 getent 验证，配置值写进去不等于解析链已经按新服务器工作。
给业务连接设置不提供默认路由，保留管理出口。此片段适用于明确设计为内部业务网络的 profile；禁止默认路由之前确认该连接没有承担实际出口，避免切断应用依赖。
sudo nmcli connection modify "business-net" ipv4.never-default yes
sudo nmcli connection modify "mgmt-static" ipv4.route-metric 100
路由 metric 只是选路因素之一，策略路由和 IPv6 默认路由仍可能参与。验证具体业务目的地的 route get，不能只看主路由表顺序。
添加明确的静态业务路由，把特定网段流量送到对应网关。示例网段和下一跳需要符合真实网络，下一跳通常必须可达；路由通过 profile 持久化，不只用临时 ip route。
sudo nmcli connection modify "business-net" +ipv4.routes "198.51.100.0/24 192.0.2.254 200"
nmcli -g ipv4.routes connection show "business-net"
路由生效后检查源地址和回程路径。出站路由正确但对端没有回程时仍会超时，抓包与网络侧日志可以帮助确认，不盲目调内核参数。
SSH 登录，先查认证链再加固
SSH 涉及网络可达、服务监听、用户状态、密钥权限、PAM 和安全策略。服务正在运行不意味着允许某个用户从某个来源登录。配置文件还可能存在 Include 与 Match，很多全局选项采用先匹配值生效，直接在文件末尾追加同名键不一定改变实际行为。应使用 sshd -T 读取有效配置。
检查 sshd 服务和实际监听，区分服务失败与端口不可达。发行版服务名以本机为准，常见服务器使用 sshd；监听地址只在回环或指定网卡时，另一地址连接失败是预期结果。
systemctl status sshd --no-pager
ss -lntp | grep -E ":22\b|sshd"
先确认端口再查防火墙。不要在没有控制台的情况下把 ListenAddress 改成尚未生效的新地址，这会让旧管理入口立即无法建立新连接。
验证配置语法并读取全局有效值，避免追加无效配置。sshd -t 不启动服务，它能发现语法和密钥相关错误；-T 输出生效配置，更适合确认 Include 和默认值影响。
sudo sshd -t
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|pubkeyauthentication|usepam|port|listenaddress"
语法通过不证明某用户可以登录，Match 条件还会改变结果。对关键账户应继续用 -C 指定来源和身份，检查最终认证策略。
按用户和来源解析 Match 后的有效配置，验证策略是否误伤管理账户。示例来源地址要替换真实堡垒机，host 是客户端主机名条件，不能用服务器地址随意代替。
sudo sshd -T -C user=ops,host=admin.example.com,addr=192.0.2.30 | grep -E "authenticationmethods|passwordauthentication|allowusers|allowgroups|forcecommand"
不同来源可能走不同策略。配置审校应覆盖自动化账户和管理员，不只验证当前 root 会话；旧连接保持不等于新认证条件正确。
读取 SSH 认证日志，定位用户、密钥或 PAM 拒绝。不同发行版可能还写 /var/log/secure，journal 提供统一入口；失败原因应与客户端详细输出同时间对齐。
sudo journalctl -u sshd --since "30 minutes ago" --no-pager -o short-iso
sudo tail -100 /var/log/secure
日志不存在时按本机日志配置查，不为执行命令随意创建空文件。Invalid user、bad ownership 和认证失败各有修复方向，不统一重置账户密码。
检查管理用户状态、有效期和 shell，确认不是账户策略阻止登录。passwd -S 的锁定标记与密码过期不同，chage 显示有效期；shell 不可登录时密钥正确也可能失败。
getent passwd ops
sudo passwd -S ops
sudo chage -l ops
修账户之前确认是人工管理用户还是限制用途的服务用户。应用账户设置 nologin 可以是正确策略，不应为了 SSH 排障把所有服务账户改成可登录。
检查 SSH 目录和公钥文件的逐级权限，定位 StrictModes 拒绝。只看 authorized_keys 本身不够，父目录属主或可写权限也会导致拒绝；使用数值身份和真实路径比凭用户名更可靠。
sudo namei -l /home/ops/.ssh/authorized_keys
sudo stat -c "%n %a %U:%G" /home/ops /home/ops/.ssh /home/ops/.ssh/authorized_keys
正确权限应结合账户和目录设计，不机械递归 chmod 整个 home。共享目录和 ACL 可能有业务用途，精确修复密钥相关路径即可。
在客户端开启详细输出，观察使用了哪个密钥及服务器拒绝阶段。示例地址属于文档网段，需要替换；verbose 输出不含私钥内容，但仍可能暴露账号和内部主机信息，分享前脱敏。
ssh -vvv -o IdentitiesOnly=yes -i ~/.ssh/ops_ed25519 ops@192.0.2.20
确定客户端实际提交的密钥指纹后再查服务器。多个 agent 密钥可能触发尝试次数限制，显式身份对照比不断改服务端 MaxAuthTries 更有定位意义。
SSH 加固与 sudo，避免把自己锁在外面
加固应该先建立可用密钥入口，再限制密码与 root 登录。密码登录关闭还要考虑 keyboard-interactive 和 PAM 行为，不能只改一个键就宣称所有口令认证都禁用。国密或厂商定制密码模块可能有特别要求，算法列表应以产品认证与实际客户端兼容性为准，不复制过时算法清单。
在受控客户端生成管理密钥，私钥设置口令并由本人保管。密钥类型需符合系统策略和认证要求，某些受限环境可能不允许 Ed25519，应采用批准算法，不因教程默认值绕过策略。
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/ops_ed25519 -C "ops-admin"
私钥不上传服务器，也不进入交付包。团队账号管理应有人员离职撤销流程，密钥登录的安全性来自身份与生命周期管理，不只来自算法名称。
在服务器为指定账户安装公钥并设置最小路径权限。authorized_keys 文件需要事先通过可信方式送达，此命令会覆盖目标文件，已有其他合法密钥时应审校合并而不是直接覆盖。
sudo install -d -m 700 -o ops -g ops /home/ops/.ssh
sudo install -m 600 -o ops -g ops ops_ed25519.pub /home/ops/.ssh/authorized_keys
确保公钥内容对应正确人员，验证指纹后再授权。若采用集中目录或证书登录，应遵循现有体系，不另建脱离审计的本地绕过入口。
准备 SSH 加固片段，并明确 Include 顺序影响。片段只有在主配置适当位置 Include 后才生效，键的最终值用 -T 验证；禁止 root 前确保普通用户可以登录并按需 sudo。
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 30
某些旧 OpenSSH 版本使用旧选项名，先查看本机手册。不要无依据关闭 UsePAM，账户与会话策略可能依赖它；确认客户端和自动化认证兼容再加载。
对密钥限制来源和不需要的转发能力，适用于用途明确的自动化账户。下面 authorized_keys 示例公钥体是占位符，不能原样使用；管理员需要交互功能时不要套用全部限制。
from="192.0.2.30",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA替换真实公钥 automation
来源限制要考虑堡垒机出口和高可用地址。业务依赖隧道时关闭转发会破坏功能，应给账户单独设计，而不是对所有密钥添加相同限制。
为运维账户设计命令范围明确的 sudo 规则，并用 visudo 检查。允许 systemctl 的任意参数或可编辑服务文件可能形成更高权限路径，最小命令列表要结合文件所有权评估。
ops ALL=(root) /usr/bin/systemctl status app.service, /usr/bin/systemctl restart app.service
示例文件放入 /etc/sudoers.d/ops-app，root 所有且权限受限。app.service 和其执行脚本若 ops 可写，重启权限可能实际等同 root 执行任意内容，必须一起审校。
检查 sudo 配置语法与账户实际授权，保证权限修改可以预测。-l 以账户身份解析授权，命令路径应与实际安装一致；语法正确仍不能证明规则范围足够小，需要审校可写脚本和参数。
sudo visudo -cf /etc/sudoers
sudo -l -U ops
避免为了发布方便把整个账户设成免密任意 sudo。自动化需要非交互操作时，给出特定命令、受控参数和审计记录，保持任务权限边界。
配置验证通过后 reload SSH，并从第二终端建立新连接。reload 通常不终止现存会话，但最终行为以版本和服务单元为准；确认新密钥登录和 sudo 后才退出旧管理会话。
sudo sshd -t && sudo systemctl reload sshd
# 在管理客户端新开终端执行
ssh -o PasswordAuthentication=no -i ~/.ssh/ops_ed25519 ops@192.0.2.20
新连接失败时利用现有会话或控制台恢复备份。验证要覆盖管理员、自动化和允许来源，不能只测试本机 localhost 就宣布远程加固成功。
systemd 服务，查清启动与运行的区别
服务能启动不代表功能正常，systemd 管理进程状态，业务需要自己的就绪和健康验证。单元文件、drop-in、环境文件和执行脚本共同决定运行行为，shell 中直接执行成功并不保证作为服务成功。用户、工作目录、环境、权限和资源限制都要从实际服务配置读取。
读取服务单元及覆盖文件，确定实际 ExecStart 和启动用户。多个 drop-in 会按顺序参与配置，不应只看 /usr/lib/systemd/system 中原文件；发行版更新也可能改变基础单元。
systemctl cat app.service
systemctl show app.service -p User -p Group -p ExecStart -p WorkingDirectory -p EnvironmentFiles
以显示的实际路径检查脚本权限和依赖。配置中环境变量不一定按交互 shell 方式展开，不能把 shell 命令串直接放进 ExecStart 期待自动解释。
读取服务状态与最近日志，识别退出原因和重启循环。只看 Active 状态可能错过反复失败后短暂运行的实例；退出码、信号和第一条日志提供更明确的故障入口。
systemctl status app.service --no-pager --full
journalctl -u app.service --since "30 minutes ago" -o short-iso --no-pager
若是 StartLimit 命中，先修根因再 reset-failed。提高重试上限只会增加失败次数，可能把依赖服务或日志分区一起压垮。
建立一个权限明确的普通服务单元，示例程序必须真实存在。Type=simple 适用于前台进程，不能配合自行后台化而不调整管理方式；User 与目录权限在启动前准备。
[Unit]
Description=Example application
After=network.target
[Service]
Type=simple
User=appsvc
Group=appsvc
WorkingDirectory=/opt/app
ExecStart=/opt/app/bin/server --config /etc/app/app.conf
Restart=on-failure
RestartSec=5s
TimeoutStopSec=60s
[Install]
WantedBy=multi-user.target
network.target 不保证远端服务已可访问，应用仍需重试策略。需要 network-online 的环境也要正确配置等待服务，不能把排序关系当连接成功保证。
验证单元语法，再重新加载配置并启动。daemon-reload 只让 systemd 读取新定义，不自动重启所有服务；实际业务变化需要明确 restart 或其他支持的操作。
sudo systemd-analyze verify /etc/systemd/system/app.service
sudo systemctl daemon-reload
sudo systemctl enable --now app.service
验证可能提示缺失二进制或依赖，应修复后再发布。GPU 节点上重载还要考虑特定旧运行时的设备访问问题，维护流程应有相关回归。
使用 drop-in 增加资源限制，保留发行版或软件包自带单元。限制值需要依据业务负载，不是所有程序都适合一吉字节内存；超过限制可能被终止，设置前先测峰值。
[Service]
MemoryMax=1G
CPUQuota=200%
TasksMax=512
LimitNOFILE=65536
保存于 app.service.d/override.conf 后 verify 和 daemon-reload。CPUQuota 两百百分比大致表示两个 CPU 时间配额，不等于固定绑定两核，也不能代替容量规划。
读取服务实际限制和当前资源，核对配置是否已经应用。文件改了但服务未重建或启动方式不同，可能仍使用旧值；服务视图比当前登录 shell 的 ulimit 更能说明真实进程条件。
systemctl show app.service -p MainPID -p MemoryCurrent -p MemoryMax -p TasksCurrent -p TasksMax -p LimitNOFILE
必要时检查 MainPID 的 /proc 限制。主机总体资源充足不意味着服务限额足够，定位 OOM 要区分内核全局回收与 cgroup 内存限制。
用独立健康请求验证服务功能，避免进程存活但不可提供业务。示例地址与接口由应用实际实现，状态码成功还需检查响应内容；只监听端口不代表依赖数据库和初始化已完成。
curl --fail --max-time 5 http://127.0.0.1:8080/health
ss -lntp | grep ":8080"
把进程状态和功能结果分开记录。日志、健康接口和请求指标一起可以解释启动期、运行期与依赖故障，不靠反复 restart 维持短暂恢复。
防火墙，确认 zone 与实际数据路径
firewalld 的规则与接口、来源所在 zone 有关。同样添加一个端口，在错误 zone 里不会影响目标接口。运行配置和永久配置也不同，运行时测试成功后再持久化。不要直接清空 nftables 或 iptables 规则来试通，容器、虚拟化和其他安全组件可能依赖这些规则。
查询 firewalld 状态和活动 zone，确认目标接口与来源对应关系。默认 zone 不代表所有流量都在该区，显式绑定接口或来源会改变匹配；查看实际活动状态才有排障价值。
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone
主机未使用 firewalld 时，应查真正管理规则的组件。不要为了执行本节步骤临时启动它覆盖现有 nftables 管理方案，职责必须清晰。
读取目标 zone 的运行和永久规则，判断重启后是否会变化。两份结果不同可能来自尚未持久化的临时变更，也可能是长期漂移；先理解差异再决定采用哪一份作为权威。
sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --permanent --zone=public --list-all
业务端口应明确协议与来源。只是服务监听并不要求全网放行，数据库和管理入口通常限定来源更合适，避免公开暴露后再依赖密码强度。
临时按来源开放示例业务端口，用短时间窗口验证。文档网段需要替换，运行规则带超时会自动移除；验证成功后再加入永久规则，避免错误操作在主机重启后长期保留。
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" port port="8080" protocol="tcp" accept' --timeout=300
来源网段必须包含实际访问者与代理出口。临时规则到期后连接情况可能变化，测试记录要写明窗口，不能把五分钟后失败误判成应用回归。
把已验证的精确规则写入永久配置，随后有计划地 reload。reload 会按永久配置重建运行配置，之前仅存在运行态的其他规则可能丢失，所以先审校全量差异。
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" port port="8080" protocol="tcp" accept'
sudo firewall-cmd --reload
reload 前确认现有 SSH 入口在永久规则中被允许。变更应包含新连接测试和旧业务回归，避免端口放通同时让另一个仅临时放行的关键服务断开。
检查实际内核规则，识别 firewalld 之外的组件影响。只读 nft 列表可以帮助判断容器 NAT、过滤和链路顺序，但直接修改其自动生成表可能被管理器下一次刷新覆盖。
sudo nft list ruleset
sudo iptables-save
命令支持情况依后端而定。判断规则归属以后通过权威工具修改，不能把 nft 与 iptables 文本混合复制到系统，可能导致重复或冲突。
抓取有限数量的目标端口报文，判断 SYN 到达与返回。抓包具有数据可见性，限制接口、端口、数量和权限；只用于授权服务器排障，输出分享前脱敏业务地址。
sudo tcpdump -ni eno1 -c 30 "tcp port 8080"
看到 SYN 而没有 SYN-ACK，继续查本机监听与过滤；双向握手完成却应用失败，转向协议和服务。包到不了本机则查上游 ACL、路由和负载均衡。
撤销本次新增的精确永久规则，完成可控回滚。该命令与添加规则字符串一致，不能用删除全部规则替代；操作后 reload 前仍要确认其他运行与永久差异不会被意外改变。
sudo firewall-cmd --permanent --zone=public --remove-rich-rule='rule family="ipv4" source address="192.0.2.0/24" port port="8080" protocol="tcp" accept'
sudo firewall-cmd --reload
回滚是恢复原安全边界，不只恢复连通性。验证原业务和管理入口，记录哪些规则回到原状态，避免维护后留下未知来源的长期开放端口。
安全机制与软件更新，按发行版维护
openEuler 与麒麟的安全机制需要按产品版本区分。SELinux 存在时用它的审计和标签工具；麒麟特定完整性、执行控制或 KYSEC 机制则按厂商安全指南检查，不用关闭 SELinux 的方法代替。软件更新也要看厂商安全公告与回补状态，不能仅用上游版本号扫描结论做最终判断。
检查 SELinux 是否启用，并读取内核可用安全模块。工具不存在时按发行版实际机制继续调查，不能据此说系统没有安全控制；多个模块可能共同影响应用访问。
command -v getenforce >/dev/null && getenforce
cat /sys/kernel/security/lsm 2>/dev/null || true
记录实际状态，不主动切成 permissive。麒麟的厂商安全机制可能独立发挥作用，服务执行被拒绝时还要检查相应厂商审计和许可策略。
收集近期安全拒绝事件，定位进程、路径与类型。只有把拒绝与业务失败对应起来，才有必要设计许可；无关扫描或错误访问不应因为在同一窗口出现就被一并放行。
sudo ausearch -m AVC,USER_AVC -ts recent -i
sudo journalctl -k --since "30 minutes ago" | grep -iE "denied|security|kysec"
命令是否支持取决于本机组件。提交厂商工单时附产品版本、补丁和拒绝时间，避免用网络上的未知安全命令强行修改执行标签。
检查应用文件的安全标签与路径权限，区分传统权限和强制访问控制。chmod 允许不代表 SELinux 允许，标签正确也不代表用户拥有文件读写权；两层都要根据证据核对。
ls -lZ /opt/app /opt/app/bin/server /etc/app/app.conf
namei -l /opt/app/bin/server
安全标签工具缺失时改用对应产品方法，不编造兼容命令。应用移动目录后可能失去原标签，修复应恢复预期策略，而不是全机关闭安全机制。
在 SELinux 路线预览默认标签恢复，先看变化再决定应用。restorecon 不创建任意许可，它按系统策略恢复文件标签；自定义业务目录若没有规则，可能需要经过审校的 fcontext 设置。
sudo restorecon -nRv /opt/app /etc/app
预览没有变化不代表权限一定正常，继续查审计。真正应用时移除 -n，并只针对相关路径；不要递归重标记全系统作为一次应用部署的常规步骤。
查询启用的软件仓库，确认来源属于当前发行版和批准介质。麒麟与 openEuler 仓库不应混装，第三方仓库的基础库升级尤其需要评估；软件安装能成功不等于厂商支持有效。
if command -v dnf >/dev/null; then
dnf repolist --enabled
else
yum repolist enabled
fi
保留仓库文件与签名配置。临时解决依赖时不要关闭 gpgcheck，离线包也需要来源与签名链；基础系统更新应有克隆环境回归。
查看安全更新信息，以发行版公告而非上游版本号作为补丁依据。不同仓库可能没有完整 updateinfo 元数据，命令无结果需要查官方公告，并不代表系统不存在待修复漏洞。
sudo dnf updateinfo list --security
sudo dnf check-update
dnf check-update 的特定非零退出码可以表示有可用更新，不应误当命令故障。更新前备份关键配置并确认内核重启要求，不能只安装包而永远不完成生效。
用 RPM 校验定位软件包文件变化，但不要自动把所有变化当攻击。配置文件被运维修改是正常现象，二进制校验变化则需进一步查部署或安全事件；校验依赖包数据库本身可信。
rpm -V openssh-server systemd NetworkManager
rpm -q --changelog openssh-server | head -60
结合变更记录、补丁说明与文件来源判断。不能为了清空校验差异强行覆盖合法配置，否则 SSH、网络和业务服务可能被恢复成不适合当前环境的默认值。
审计、日志与时间，保证证据不会丢失
安全加固不仅是拒绝访问，也要让合法运维动作可追踪。日志应有持久化、容量限制和时间同步，审计规则则限制范围避免压垮系统。记录用户、操作时间和对象，才能区分自动化变更、配置漂移与真实入侵。日志里的秘密应控制访问，不能为了排障把所有环境输出长期保存。
检查 journal 存储占用与日志保留情况，确认重启后证据是否存在。默认存储模式依发行版配置，日志在内存中时可能随重启消失；事故复盘需要知道能查到的时间范围。
journalctl --disk-usage
journalctl --list-boots
ls -ld /var/log/journal
多次启动记录不一定证明无限期持久化，仍看实际配置。日志空间预算应与磁盘容量和保留要求一致，避免日志把根分区写满影响 SSH 与业务。
配置 journald 持久存储与容量上限，作为经过容量评估的片段。示例限制两吉字节只是教学值，按日志速率和保留天数计算；关键审计与集中日志还有独立要求。
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
Compress=yes
保存到本机支持的 journald.conf.d 目录并检查加载方式。持久日志限制不会自动满足合规留存，重要日志需要异地汇集与完整性保护。
查询指定启动与服务的结构化日志，用时间范围把故障证据集中。原始日志可能有令牌、账号和业务输入，交付前脱敏；不要用截断最后一行替代完整错误链。
journalctl -b -u sshd -u NetworkManager --since "2026-09-30 10:00:00" --until "2026-09-30 10:30:00" -o short-iso
日期时间是教学示例，换成真实故障窗口。明确日志使用时区，跨机器关联先校准时间，否则两个相邻事件可能被错误排序。
查看 chrony 时间源和偏差，验证同步状态而不是只看系统当前时间。服务正在运行不代表有可用时间源，网络和认证限制会影响同步；关键系统对偏差容忍需独立规定。
chronyc tracking
chronyc sources -v
systemctl status chronyd --no-pager
不同时间工具按实际安装选择。不要在运行数据库时无评估地大幅跳时，修正方式和维护安排应根据应用行为与同步策略确定。
检查 auditd 状态和已加载规则，确认审计链路在运行。内核审计与服务日志各有覆盖范围，规则过多可能带来性能与磁盘压力；先读现有策略，不重复添加同义规则。
systemctl status auditd --no-pager
sudo auditctl -s
sudo auditctl -l
lost 计数和 backlog 有助于发现审计丢失风险。规则变更应由安全策略维护入口执行，某些模式禁止运行时修改，需要在计划重启窗口处理。
为关键 SSH 配置添加审计关注规则，控制监视范围。以下是传统 watch 语法示例，目标版本是否推荐该语法以本机 audit 文档为准；它记录写入与属性变化，不应扩展到整棵文件系统。
-w /etc/ssh/sshd_config -p wa -k ssh_config_change
-w /etc/sudoers -p wa -k sudo_policy_change
-w /etc/sudoers.d/ -p wa -k sudo_policy_change
存入受控 rules.d 文件后按本机工具加载。审计密钥便于检索，规则生效与日志落盘都要验证，不能只确认文件写入成功。
按审计 key 查询配置修改记录，关联用户与变更时间。日志可能同时记录进程有效身份和最初登录身份，两者有助于解释 sudo 操作；核对合法工单后再判断是否未授权。
sudo ausearch -k ssh_config_change -ts today -i
sudo ausearch -k sudo_policy_change -ts today -i
审计记录不自动给出操作意图，仍需要变更单和发布记录。恢复配置前保存证据，避免覆盖文件以后失去判断修改来源的机会。
最小权限与服务加固，按功能验证
服务加固需要结合真实访问需求。只读系统目录、私有临时目录、限制能力和资源边界可以减少风险，但会改变应用运行条件。数据库、GPU 计算、网络代理和容器管理程序需要的能力不同，不能给所有服务套同一模板。每加一项约束，都要用功能测试验证并记录允许写入路径。
创建不可交互登录的服务账户，隔离应用进程与管理员身份。账户名和目录是示例，已有账户不要重复创建；业务需要专用 home 或证书缓存时可按需求配置，而非授予 SSH 登录。
sudo useradd --system --home-dir /var/lib/app --create-home --shell /sbin/nologin appsvc
getent passwd appsvc
nologin 路径以本机存在文件为准。服务文件和二进制仍由受控发布账户或 root 管理，不要让应用账户可以修改自己的 root 启动脚本。
设置应用配置与数据目录权限，把只读配置和可写状态分开。密钥配置不应对其他普通用户可读，数据目录由服务账户写入；不要用递归七七七掩盖权限和所有权错误。
sudo install -d -m 750 -o root -g appsvc /etc/app
sudo install -d -m 750 -o appsvc -g appsvc /var/lib/app
sudo chown root:appsvc /etc/app/app.conf
sudo chmod 640 /etc/app/app.conf
文件存在后再执行相关命令。程序目录、配置和状态采用不同所有权，可以降低业务进程被利用后篡改程序的机会，同时保持合法运行。
给普通 Web 服务加入 systemd 安全限制，先明确需要的可写目录。这个片段不适合未经验证直接用于数据库、GPU 或特权网络程序；ProtectSystem 和 PrivateTmp 可能影响既有路径访问。
[Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/lib/app
CapabilityBoundingSet=
UMask=0027
应用日志建议走 stdout 到 journal，其他缓存写入明确目录。验证上传、证书、临时文件和插件加载，功能失败时按必要路径局部放行，不撤销全部加固。
检查 systemd 的静态安全评分，作为审校提示而非绝对安全证明。评分根据单元选项计算，不理解业务依赖和威胁模型；分数低的合法系统管理服务未必错误，分数高也不保证无漏洞。
systemd-analyze security app.service
逐条看未限制项与业务必要性，再决定修改。不要为了追求满分关闭程序必要能力，安全配置的目标是明确边界并通过功能验收。
检查进程文件描述符与限制，避免负载下触及默认上限。系统总上限、登录 shell 限制和服务限制是不同层次；只能读取实际业务 PID 才能判断运行进程是否受当前配置影响。
APP_PID=$(systemctl show app.service -p MainPID --value)
cat "/proc/$APP_PID/limits"
find "/proc/$APP_PID/fd" -mindepth 1 -maxdepth 1 | wc -l
PID 为零时先确认服务已启动。描述符增长可能来自正常连接或泄漏，结合时间序列与连接状态判断，不直接无限调大上限来掩盖泄漏。
检查监听服务，建立服务器暴露面清单。只保留业务所需监听，内网管理端口也要有限来源；进程绑定所有地址与防火墙规则共同决定访问范围，不能只看其中一个。
ss -lntup
systemctl list-unit-files --state=enabled --no-pager
停用服务前确认依赖和恢复方法，不能凭陌生名字删除。厂商管理、时间同步和审计组件可能是基础能力，最小化必须依据职责而不是数量。
对加固后的服务执行代表性功能验证，检查需要读写与网络访问。示例测试仅展示入口，真实项目应覆盖上传、数据读取、依赖连接和优雅退出；未执行的测试不能在文档写已通过。
curl --fail --max-time 5 http://127.0.0.1:8080/health
journalctl -u app.service --since "5 minutes ago" --no-pager
systemctl show app.service -p Result -p ExecMainStatus
测试后确认没有新安全拒绝。加固失败的修复应解释具体路径或能力需求，避免把所有安全选项删除后只留下“恢复正常”的无依据结论。
故障恢复，控制台与配置回退
远程入口失效后，应从授权控制台或带外通道恢复，不在不清楚状态时重装系统。先判断是地址、路由、防火墙、服务还是认证策略，再恢复最小必要配置。保留失败现场与原备份，尤其安全加固误锁与文件系统损坏是不同问题，恢复顺序不能混淆。
在变更前备份 SSH 配置与 drop-in，保留权限和路径。备份目录需要受限，文件可能含访问策略；这里只复制相关配置，不把私钥或全部用户 home 打包作为通用备份。
sudo cp -a /etc/ssh/sshd_config "$OPS_DIR/sshd_config.before"
if test -d /etc/ssh/sshd_config.d; then
sudo cp -a /etc/ssh/sshd_config.d "$OPS_DIR/sshd_config.d.before"
fi
回滚时同时恢复本次影响的 Include 文件。只还原主文件而保留错误 drop-in，可能仍然使用错误策略，因此备份必须覆盖有效配置链。
在控制台先读取接口、路由和服务，明确失联层次。没有地址先恢复连接 profile；地址正常但端口没监听则查 sshd；监听正常却认证拒绝则继续账户与密钥，避免同时修改全部层次。
ip -br address
ip route show
systemctl status NetworkManager sshd firewalld --no-pager
控制台下也应记录时间和原错误。修复过程中保持最小动作，若系统根卷只读或空间耗尽，先解决基础文件系统问题再加载配置。
从保存的回退 profile 恢复管理网络，适用于 NetworkManager 主线。这个命令可能改变接口地址与会话，应该在控制台执行；恢复以后核对 DNS 和具体业务路由，不只测试网关。
sudo nmcli connection up "mgmt-before-change"
nmcli connection show --active
ip route get 192.0.2.30
克隆 profile 默认自动连接关闭，恢复后按原策略决定是否启用。不要把失败的新 profile 立即删除，保留用于审查差异，确认原因后再整理。
恢复本次变更前的 SSH 主配置并做语法验证，成功才加载。若错误发生在 drop-in，也要撤销或恢复对应文件；不要在控制台临时允许所有 root 密码登录作为唯一恢复动作。
sudo cp -a "$OPS_DIR/sshd_config.before" /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload sshd
恢复后从真实允许来源建立新连接。默认值或备份文件也可能与其他变更不一致，核对时间和工单，避免恢复过旧策略带来新的暴露面。
检查服务启动失败是不是被限流，修复配置后清理失败状态再启动。reset-failed 不是修复程序，它只重置失败与启动频率相关状态；在根因未解决前执行会继续循环失败。
sudo systemctl reset-failed app.service
sudo systemctl start app.service
systemctl show app.service -p Result -p ExecMainStatus
立即看日志和健康接口，确认真正恢复。若失败是权限、缺文件或挂载问题，按证据修复，不通过降低全部安全限制来“先启动再说”。
查看 OOM 与文件系统内核事件，区分配置误锁和系统容量故障。SSH 接受连接后立即退出，可能与内存压力或磁盘不可写有关；这时只恢复认证配置不会解决基础资源问题。
sudo journalctl -k --since "1 hour ago" | grep -iE "out of memory|oom|I/O error|read-only|ext4|xfs"
保留错误并确认设备健康，文件系统修复需要相应卸载或恢复流程。不要在挂载中的关键数据卷上照抄 fsck 修复命令，先保护数据和现场。
保存故障复盘，把恢复动作与验证结果对应。模板中的项目是填写要求，不是实测结论；清楚写明是网络切换、SSH Include 顺序还是安全策略拒绝，才能防止下一次重复发生。
cat > os-incident.txt <<'INCIDENT'
Symptom and time: 待填写
OS and patch level: 待填写
Last change: 待填写
Failure layer: network / listener / auth / policy / resources
Evidence: 待填写
Rollback performed: 待填写
New SSH connection: 待填写
Business health: 待填写
Follow-up test: 待填写
INCIDENT
恢复成功也要记录安全边界是否保持原要求。值班流程应有控制台入口、备份路径和权限责任人，不依赖已经断开的 SSH 作为唯一通道。
交付与日常巡检，让基线持续有效
日常巡检应关注变化而不只是打印很多命令。资产版本、网络 profile、SSH 有效策略、服务资源和安全更新形成基线，每次维护比较差异。巡检脚本以只读为主，自动修复则针对明确、可验证、可回退的条件，不把未知状态统一重启或放开权限。
编写只读巡检骨架，采集基础状态并在命令失败时保留错误。脚本不执行更新和修复，输出目录限制权限；真实部署需要按系统工具可用性适配，不能因缺命令跳过关键检查。
#!/usr/bin/env bash
set -u
umask 077
out="health-$(date +%Y%m%d%H%M%S).log"
{
date -Is
cat /etc/os-release
systemctl --failed --no-pager
ip -br address
ip route show
df -hT
df -i
ss -lntup
} > "$out" 2>&1
printf "%s\n" "$out"
日志只供授权维护者使用。定期任务中 PATH 与交互环境不同，应使用受控环境或绝对路径，避免巡检悄悄失败而无人发现。
通过 systemd timer 定期执行巡检，明确脚本位置与运行身份。示例服务以 root 读取部分系统信息，脚本由 root 管理且不可被普通用户修改；不要给可写脚本配高权限定时执行。
[Unit]
Description=Read-only server health snapshot
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/server-health.sh
WorkingDirectory=/var/log/server-health
UMask=0077
这是 server-health.service 示例，需要先创建脚本和目录。巡检输出要有轮转与保留策略，不能让监控脚本自己最终填满日志分区。
为巡检服务配置小时级定时器，使用随机延迟分散多节点同时采集。Persistent 会补触发错过的日历任务，重启后行为需理解；并不保证每小时精确同一秒执行。
[Unit]
Description=Schedule server health snapshot
[Timer]
OnCalendar=hourly
RandomizedDelaySec=5m
Persistent=true
[Install]
WantedBy=timers.target
定时器与服务同名关联，加载后检查 next 与 last 时间。业务关键监控仍应实时采集，小时快照用于配置和容量基线，不代替故障告警。
检查定时器与最近运行日志，验证任务实际执行而不是只有文件存在。启用动作在批准后执行，示例先验证单元；定时任务失败要有告警或集中日志，不能依赖人工偶尔查看。
sudo systemd-analyze verify /etc/systemd/system/server-health.service /etc/systemd/system/server-health.timer
systemctl list-timers server-health.timer --all
journalctl -u server-health.service --since "1 day ago" --no-pager
脚本退出码和输出文件都要检查。权限问题、目录不存在和 PATH 差异常使手工可运行脚本在服务中失败，巡检本身也需要一次实际验收。
对关键配置建立哈希基线，发现变化后关联工单。哈希只说明内容变化，不说明变化恶意；配置由自动化系统维护时应将其变更记录一同保存，避免合法发布反复产生噪声。
sudo sha256sum /etc/ssh/sshd_config /etc/sudoers /etc/chrony.conf > "$OPS_DIR/config-baseline.sha256"
sudo sha256sum -c "$OPS_DIR/config-baseline.sha256"
Include 文件和网络 profile 应按实际范围加入。配置完整性不是应用健康，未变化配置也可能因为系统升级、依赖变化或外部网络改变而不再有效。
建立服务器交付清单，明确当前网络管理与安全机制。模板没有自动给出合规结论，每项需要实际验证；产品特定安全策略注明厂商文档版本和维护入口，避免后人套错通用命令。
cat > server-handover.txt <<'HANDOVER'
OS / release / architecture: 待填写
Approved repositories: 待填写
Network manager and profile UUID: 待填写
Management address and rollback: 待填写
SSH effective policy and access owner: 待填写
Services and writable paths: 待填写
Firewall zone and allowed sources: 待填写
SELinux / vendor security mechanism: 待填写
Audit and log retention: 待填写
Patch and reboot plan: 待填写
HANDOVER
交付清单让值班人员知道系统应是什么状态，以及哪份配置是权威。真正维护质量来自可解释、可验证的状态，不是执行一串命令后留下一句“已加固”。
对上线前后的关键服务进行统一验证，记录新连接、健康与日志。实际项目用自身服务名替换，命令只提供结构；不要把未执行的命令列在交付记录中并标为通过。
systemctl is-active sshd NetworkManager app.service
curl --fail --max-time 5 http://127.0.0.1:8080/health
journalctl --since "10 minutes ago" -p err --no-pager
还需要从允许的远程来源验证 SSH 和业务端口，并从不允许来源验证限制。既证明合法功能正常，也证明安全边界成立，才是完整上线验收。
一个虚构案例发生在麒麟服务器远程改 IP 时。管理员修改了保存的 profile，却没有检查哪个 profile 正在活动；随后重启 NetworkManager，新配置抢占管理网卡，旧会话断开。由于只记录了新地址，没有保存原连接 UUID，控制台恢复耗时很长。正确流程是先读取活动连接、克隆原 profile、关闭新 profile 自动连接，再通过支持的 checkpoint 或控制台激活，在另一个终端验证新 SSH、DNS 与业务路由。确认后才开启自动连接并记录回退对象。可回退不是多写一句注意，而是实际保留能够执行的恢复路径。
另一个案例中，管理员在 sshd_config 末尾追加 PasswordAuthentication no，自认为密码已关闭，但主文件前部 Include 的片段先设置了 yes，实际有效值仍允许密码。随后又为了彻底关闭登录把 UsePAM 设为 no，造成依赖 PAM 账户策略的自动化用户异常。正确做法是读取 -T 与按来源解析的 -T -C，审查 Include 顺序与 Match 条件，分别控制 password 和 keyboard-interactive，并保留所需账户与会话策略。配置文本中出现某个键，不等于服务最终采用该值。
安全策略误判也常见。应用文件 chmod 已经允许执行，但厂商完整性或执行控制仍拒绝，运维人员反复改 Linux 文件权限却没有效果。这个现象说明拒绝发生在另一层，需要读取产品安全审计并按对应版本维护策略。关闭 SELinux 既可能无效，也可能降低其他应用隔离。先确认机制、证据和厂商支持入口，再做局部调整，比把全部安全控制关闭更可靠。
日常维护最终要保留清晰的系统身份与权威配置：软件来自哪里，网络由谁管理，SSH 对哪个用户与来源采用什么策略，服务以谁运行并写哪些目录，防火墙规则属于哪个 zone，审计保留多久，安全更新何时生效。麒麟与 openEuler 的共通部分可以复用方法，差异部分必须按版本核对。把这些信息落实到备份、验证和交付中，服务器才能在持续升级与人员交接后保持可维护。
参考资料
- 银河麒麟高级服务器系统与产品文档入口
- openEuler 系统管理员指南
- openEuler SSH 与系统服务安全加固
- NetworkManager nmcli 手册
- OpenSSH sshd_config 手册
- firewalld 官方文档
- systemd 官方手册
发表于 3 小时前
|
查看: 0|
回复: 0
