如何在Linux中配置具体的安全加固项

PermitRootLogin 必须设为 no，这一点没什么可商量的。直接允许 root 远程登录，等于把暴力破解的最大目标送到攻击者面前——他们连用户名都不用猜，只要专注爆破 root 密码就行，而默认配置下这个通道是敞开的。设为 no 之后，SSH 会直接拒绝所有以 root 身份发起的连接请求，哪怕密码正确也进不来。这不是换个登录方式，而是彻底堵死最危险的路径。

PermitRootLogin no 为什么必须设为 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，这是常见失败原因

AllowUsers 只放必要账号，不是“加白名单”那么简单

AllowUsers 是细粒度控制的第一道闸门，但它不是“加几个用户名就完事”。真实生产环境里，它常和来源 IP、shell 类型耦合使用。

例如只允许运维组从内网跳板机登录，或禁止某账号用 /bin/bash 直接交互，只允许执行固定命令。

• 语法支持 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 服务可能启动失败。每一步验证都要落到具体命令输出，而不是“改了就算完成”。