必须禁用 root 远程登录并启用密钥认证，配置 AllowUsers 白名单、限制 MaxAuthTries 和 ListenAddress，结合 fail2ban 与日志审计强化 ssh 安全。
禁用 root 远程登录必须做
直接允许 root 通过 SSH 登录是绝大多数入侵事件的入口。即使你确信密码够强，也挡不住暴力扫描 + 密码复用组合拳。
操作上不是简单改 PermitRootLogin yes 为 no 就完事——得确认普通用户已具备 sudo 权限且能免密执行关键命令（如重启服务），否则可能把自己锁在外面。
- 编辑
/etc/ssh/sshd_config，设PermitRootLogin no - 确保目标用户（如
deploy）在/etc/sudoers中有明确授权，例如：deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx - 重启前用
sshd -t检查配置语法，再用新终端测试登录，别在唯一会话里 reload
密钥登录要关掉密码认证
启用公钥认证后，如果还留着 PasswordAuthentication yes，等于给攻击者留了条后门——只要爆破到任意一个弱口令账户，就能进系统。
注意：不是所有密钥都安全。默认 ssh-keygen 生成的 RSA-2048 已不够稳妥，OpenSSH 8.8+ 默认已禁用 ssh-rsa 签名；新部署建议用 ed25519。
- 生成密钥时用
ssh-keygen -t ed25519 -C "admin@prod" - 服务端设
PasswordAuthentication no和PubkeyAuthentication yes - 客户端连接时加
-o PreferredAuthentications=publickey强制跳过密码环节，避免交互式 fallback
限制登录来源 IP 和失败次数
SSH 是暴露在公网最久、被扫最勤的服务，光靠强认证不够，得从网络层和应用层双重收敛。
AllowUsers 比 DenyUsers 更可靠，白名单思维比黑名单更可控；而 MaxAuthTries 设太低（比如 2）反而容易被误杀，太高（6+）又失去意义。
- 用
AllowUsers deploy@192.168.10.* deploy@2001:db8::/64锁死可信网段 -
MaxAuthTries 3+Maxsessions 2防并发撞库 - 配合
fail2ban监控/var/log/auth.log，对 5 分钟内失败 4 次的 IP 封 1 小时（iptables或nftables后端）
改默认端口不如配合监听地址控制
把 SSH 改成 Port 2222 只能防脚本小子，对定向扫描毫无作用，反而增加运维记忆负担和自动化工具适配成本。
真正有效的做法是：让 SSH 只监听内网或跳板机可访问的地址，彻底不在公网暴露。如果必须对外，就用 ListenAddress 绑定特定公网 IP（比如只开给堡垒机弹性 IP），而不是全网卡通吃。
- 查当前监听：
ss -tlnp | grep :22，确认没意外监听0.0.0.0:22 - 设
ListenAddress 10.0.1.5:22（内网管理网段）或ListenAddress 203.0.113.10:22（指定公网 IP） - 若用云厂商，安全组层面也要同步收紧，只放行跳板机或 CI/CD 出口 IP
密钥权限、日志审计、定期轮换这些事没人盯着就容易松懈；最常被忽略的是 sshd_config 里注释掉的选项——比如 #LogLevel INFO 被注释后实际走默认 INFO，但很多人以为是 WARNING，结果关键登录事件根本没记全。