可以直接在/etc/ssh/sshd_config里收紧SSH登录安全策略：把MaxAuthTries改成3，限制单次认证尝试次数；将PermitRootLogin设为no，禁止root账户直接远程登录；把PasswordAuthentication设为no，关闭密码登录方式（前提是先正确配置好SSH公钥认证）；再通过AllowUsers明确指定允许登录的用户。修改完成后，执行systemctl restart sshd让配置立即生效，同时务必保留一个已登录的终端作为备用，避免因为新配置错误把自己锁在服务器之外。
怎么改 sshd_config 里的登录限制参数
直接修改 /etc/ssh/sshd_config 是 CentOS 7 加固 SSH 登录策略中最基础、也最关键的一步，但如果参数配置错误，可能会导致 SSH 无法连接，因此必须逐项检查并确认。
MaxAuthTries用来控制单次连接最多可尝试多少次认证，默认值通常是 6，建议调整为3：找到#MaxAuthTries 6这一行，去掉注释后改成MaxAuthTries 3PermitRootLogin决定 root 是否可以直接登录 SSH，禁用 root 直连就设置为no；如果只允许 root 使用密钥登录，可写成without-password（注意不是prohibit-password，后者在 CentOS 7 中无法识别）PasswordAuthentication如果要关闭密码登录，必须设置为no，但前提是已经配置好公钥认证，否则会直接导致远程登录被完全锁死AllowUsers或DenyUsers可以按用户名进行访问控制，例如只允许admin和deploy登录，可写为AllowUsers admin deploy
参数修改完成后，必须执行 systemctl restart sshd 重启 SSH 服务，建议同时保留一个当前已登录的终端窗口不要关闭，以防配置出错后无法重新连接服务器。
为什么 /etc/hosts.allow 和 /etc/hosts.deny 要一起用
这两个文件属于 TCP Wrappers 层的访问控制机制，在某些场景下优先级甚至高于防火墙规则，但实际运维中经常被忽略，或者因为配置顺序写错而失效。
- 先配置
/etc/hosts.deny：通常固定写成sshd: ALL，表示默认拒绝所有 SSH 来源 - 再配置
/etc/hosts.allow：只放行可信任的 IP 地址，例如sshd: 192.168.1.100: allow或sshd: 203.0.113.0/24: allow - 顺序不能写反——
hosts.allow会优先匹配，一旦匹配成功就直接放行，不再继续检查hosts.deny；因此“默认全拒绝”必须写在 deny 文件中，而 allow 文件只保留白名单规则 - 需要注意：如果同时启用了
AllowUsers，那么 IP 白名单和用户白名单之间是“且”关系，必须同时满足才能成功登录
防火墙和 SELinux 对新端口的影响
如果修改了 SSH 端口（例如把默认 22 端口改为 2222），仅仅改动 SSH 配置文件还不够，系统层面通常还有防火墙和 SELinux 两道限制需要同步放行。
- firewalld 必须明确放行新的 SSH 端口：执行
firewall-cmd --permanent --add-port=2222/tcp，然后再运行firewall-cmd --reload - SELinux 默认通常只允许 SSH 使用 22 端口，如果不额外放行，新端口会被静默拒绝。安装
policycoreutils-python后执行：semanage port -a -t ssh_port_t -p tcp 2222 - 验证是否配置成功：运行
semanage port -l | grep ssh，输出结果中应该能看到2222 - 如果暂时不想细调 SELinux，临时做法可以使用
setsebool -P ssh_port_t 1，但从稳定性和规范性来看，还是直接添加端口规则更稳妥
登录失败后自动封 IP 的脚本为什么总漏掉攻击源
很多常见脚本会从 /var/log/secure 中解析 Failed password 日志并自动封禁 IP，但在实际使用中经常漏封，主要有以下几个明显问题：
- 日志格式会随着 OpenSSH 版本变化：例如在 CentOS 7.6+ 中，日志字段位置可能发生偏移，
$(NF-3)这种写法很容易取错 IP，建议改用awk '/Failed.*from/ {print $11}'，字段定位相对更稳定 - 没有过滤内网扫描或误操作：脚本应主动排除
127.0.0.1、192.168.、10.等私有地址段，避免误封内部地址 /etc/hosts.deny不支持 CIDR 网段写法，只能封禁单个 IP；如果要封整个地址段，还是要依赖iptables或fail2ban，原生脚本本身做不到- crontab 一天只跑一次的方式太慢，真实的 SSH 暴力破解通常几分钟内就能完成扫描——更建议使用
fail2ban做实时监控和自动封禁，这才更符合生产环境的安全需求
真正要在服务器上稳定落地，不建议自己临时拼接封禁脚本，直接使用 fail2ban 配合 sshd jail 做防护，几行配置就能运行起来，整体上比手动解析日志更可靠、更适合生产环境。
