如何在Linux中配置具体的安全加固项需要先看清适用场景和关键步骤,避免只记结论却忽略实际限制。
PermitRootLogin no 必须设为 no,因为直接允许 root 远程登录是暴力破解首要入口;设为 no 后 SSH 彻底拒绝 root 登录,须先创建普通用户并赋权,再重启 sshd 服务。
直接允许 root 远程登录是绝大多数暴力破解攻击的第一入口。攻击者不需要猜普通用户名,只要爆破 root 密码就行——而默认配置下这个通道是开着的。
设为 no 后,SSH 会拒绝所有以 root 身份发起的连接请求,哪怕密码正确也进不来。这不是“换种方式登录”,而是彻底堵死这个最危险的路径。
useradd 创建一个普通用户,并用 usermod -aG sudo(Ubuntu/Debian)或 usermod -aG wheel(RHEL/CentOS)赋予提权能力,否则改完就锁死自己/etc/ssh/sshd_config,不是客户端配置;改完要执行 sudo systemctl restart sshd
no,但不能依赖——必须手动确认 grep -i "permitrootlogin" /etc/ssh/sshd_config
禁用密码登录不是为了“省事”,而是为了消灭可被自动化脚本穷举的攻击面。单设 PasswordAuthentication no 不够,必须同时确保 PubkeyAuthentication yes 生效,否则所有 SSH 登录都会失败。
密钥认证的本质是“私钥持有即身份”,不依赖记忆强度、不暴露在网络传输中,且无法被中间人截获重放。
ssh-copy-id 传公钥后,务必检查目标用户家目录下 ~/.ssh/authorized_keys 是否写入成功,权限是否为 600
ed25519 密钥(推荐),需确认服务器 OpenSSH 版本 ≥ 6.5;旧系统可能只支持 rsa,但密钥长度必须 ≥ 3072 位StrictModes yes(默认开启)——它会拒绝读取组/全局可写的 ~/.ssh 或 authorized_keys,这是常见失败原因AllowUsers 是细粒度控制的第一道闸门,但它不是“加几个用户名就完事”。真实生产环境里,它常和来源 IP、shell 类型耦合使用。
例如只允许运维组从内网跳板机登录,或禁止某账号用 /bin/bash 直接交互,只允许执行固定命令。
user@host 形式:AllowUsers [email protected]/24 [email protected],比单纯用户名更防撞库ForceCommand(如限制为只跑备份脚本),需确保该命令所在路径对用户可执行,且不触发 shell 初始化逻辑DenyUsers 混用——两者逻辑冲突时,DenyUsers 优先级更高,容易误杀几乎所有被入侵的服务器,防火墙都处于“只开 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),否则会立刻断连chain input { type filter hook input priority 0; policy drop; } 才是等效写法,policy accept 是默认陷阱DROP 策略之前;用 iptables -L -n --line-numbers 检查顺序PermitRootLogin no 失效,PasswordAuthentication no 就失去意义;AllowUsers 写错格式,整个 SSH 服务可能启动失败。每一步验证都要落到具体命令输出,而不是“改了就算完成”。