如何在Linux中配置具体安全加固项的操作步骤

在Linux安全加固的众多配置中，PermitRootLogin 必须设为 no 是一项不可妥协的底线。直接允许 root 账户远程登录，等于把暴力破解的靶心暴露给攻击者——他们无需猜测普通用户名，只需集中爆破 root 密码即可，而默认情况下这个通道始终敞开。一旦设为 no，SSH 服务将直接拒绝所有以 root 身份发起的连接请求，即使输入了正确密码也无法进入。这不是简单的登录方式变更，而是彻底封堵最危险的攻击路径。

为什么必须将 PermitRootLogin 设为 no

直接允许 root 远程登录，几乎是所有暴力破解攻击的首选突破口。攻击者不必猜测普通用户名，只需专注爆破 root 密码——而默认配置下这个通道永远敞开。

设置为 no 之后，SSH 会拒绝所有以 root 身份发起的连接请求，即使密码正确也无法进入。这并非“换个方式登录”，而是从根本上阻断这条最危险的路径。

• 修改配置之前，务必先用 useradd 创建一个普通用户，并通过 usermod -aG sudo（Ubuntu/Debian）或 usermod -aG wheel（RHEL/CentOS）赋予提权权限，否则修改后您将把自己锁在系统之外
• 修改的对象是服务器端配置文件 /etc/ssh/sshd_config，而非客户端配置；修改完成后需执行 sudo systemctl restart sshd 使配置生效
• 部分发行版（如 Rocky 9）默认情况下已经是 no，但不能掉以轻心——必须通过 grep -i "permitrootlogin" /etc/ssh/sshd_config 手动确认当前设置

PasswordAuthentication no 与 PubkeyAuthentication yes 必须联合配置

禁用密码登录的目的并非“图省事”，而是为了消除可被自动化脚本穷举的攻击面。单独设置 PasswordAuthentication no 远远不够，必须同时确保 PubkeyAuthentication yes 生效，否则所有 SSH 登录尝试都会失败。

密钥认证的核心机制是“持有私钥即证明身份”，它不依赖记忆强度、不通过网络传输密码，且无法被中间人截获或重放。

• 使用 ssh-copy-id 传输公钥后，务必检查目标用户家目录下 ~/.ssh/authorized_keys 是否成功写入，且该文件权限必须为 600
• 如果选用 ed25519 密钥（强烈推荐），需确认服务器 OpenSSH 版本 ≥ 6.5；较旧的系统可能仅支持 rsa，但密钥长度必须 ≥ 3072 位
• 切勿忽略 StrictModes yes（默认开启）——此选项会拒绝读取组或全局可写的 ~/.ssh 目录或 authorized_keys 文件，这是常见的配置失败原因

Use AllowUsers 精准控制可登录账号，而非简单添加白名单

AllowUsers 是细粒度访问控制的第一道关卡，但它的用法远不止“添加几个用户名就完事”。在生产环境中，它通常与来源 IP、shell 类型等条件组合使用。

例如，可以限制运维组只能从内网跳板机登录，或禁止某个账号使用 /bin/bash 交互式 Shell，仅允许执行固定命令。

• 语法支持 user@host 格式：AllowUsers admin@192.168.10.0/24 deploy@10.0.0.5，这种写法比单纯使用用户名更能有效防范撞库攻击
• 如果配合 ForceCommand（例如限制用户只能运行备份脚本），需要确保该命令所在的路径对用户可执行，并且不会触发 Shell 初始化逻辑
• 避免与 DenyUsers 同时使用——当两者逻辑冲突时，DenyUsers 的优先级更高，容易意外拦截合法用户

防火墙 iptables/nftables 规则必须默认设置为 DROP

大量被入侵的服务器，其防火墙配置仅仅停留在“开放 22、80、443 端口，其余不管”的状态。这相当于锁上了大门，却把所有窗户敞开着。真正的安全加固要求：所有未明确允许的流量，默认丢弃。

这不是简单添加几条 -A INPUT -p tcp --dport 22 -j ACCEPT 就结束，而是需要从策略的起点就确定方向。

• 执行 iptables -P INPUT DROP 之前，务必先插入一条允许当前 SSH 连接的规则（例如 iptables -I INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT），否则会立即断开连接
• nftables 用户请注意：chain input { type filter hook input priority 0; policy drop; } 才是等效的正确写法，policy accept 是一个常见的默认陷阱
• 规则顺序决定了匹配结果——允许规则必须放在 DROP 策略之前；使用 iptables -L -n --line-numbers 可以检查规则的顺序

最关键的认知在于：这些配置项并非孤立的开关，而是环环相扣的安全链条。例如，如果 PermitRootLogin no 失效，那么 PasswordAuthentication no 也就失去了保护作用；AllowUsers 格式书写错误，甚至可能导致整个 SSH 服务启动失败。每一步的验证都必须落实到具体的命令输出，而不是停留在“改过就算完成”的层面。