最有效且可落地的ssh安全防线是直接禁用密码登录、强制密钥认证。需创建新用户并赋权、配置allowusers白名单、手动部署密钥（注意权限与selinux）、调优fail2ban参数，并严格验证passwordauthentication no生效。
直接禁用密码登录、强制密钥认证，是目前最有效且可落地的防线。其他措施（改端口、禁root、fail2ban）都只能延缓或过滤攻击，无法从根本上阻断暴力尝试——只要密码认证开着，就永远存在被撞库成功的可能。
PermitRootLogin no 不等于安全
禁用 root 远程登录只是基础操作，但很多人忽略两点：一是没提前创建并验证普通用户能否真正提权；二是没配合 AllowUsers 白名单机制。只改 PermitRootLogin no 后，如果服务器上还留着 admin、test、ubuntu 这类常见用户名，攻击者照样能爆破这些账户。
- 必须先用
useradd -m -s /bin/bash deploy创建新用户，再用usermod -aG sudo deploy（Debian/Ubuntu）或usermod -aG wheel deploy（RHEL/CentOS）赋予权限 - 在
/etc/ssh/sshd_config中显式写入AllowUsers deploy，避免遗漏账户被利用 - 修改配置后，**务必新开一个终端用新用户登录成功，再关掉当前 root 会话**——否则锁死自己是高频事故
ssh-copy-id 失败时的替代路径
ssh-copy-id 常因目标用户 ~/.ssh 目录权限不对、authorized_keys 不存在或 SELinux 限制而失败，不能因此放弃密钥登录。
- 手动操作更可控：先
mkdir -p ~/.ssh && chmod 700 ~/.ssh，再echo "公钥内容" >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys - 若提示
Permission denied (publickey)，检查服务端/etc/ssh/sshd_config是否设了PubkeyAuthentication yes且未被注释 - SELinux 启用时，需补一句
restorecon -Rv ~/.ssh，否则 SSH 守护进程拒绝读取密钥文件
fail2ban 的 bantime 和 findtime 别照抄默认值
默认 maxretry = 5 + findtime = 600（10 分钟）+ bantime = 3600（1 小时），对真实攻击几乎无效——自动化脚本 1 秒试 3 个密码，10 分钟就是 180 次，早超阈值了。
- 生产环境建议调紧：把
findtime缩到120（2 分钟），maxretry设为3，bantime提高到86400（24 小时） - 日志路径要匹配系统：Debian/Ubuntu 是
/var/log/auth.log，RHEL/CentOS 是/var/log/secure，写错 fail2ban 就不干活 - 启用前先运行
sudo fail2ban-client status sshd确认 jail 已加载，再用sudo tail -f /var/log/fail2ban.log实时看封禁动作
真正关键的不是堆砌多少层防护，而是确认 PasswordAuthentication no 这一行是否生效且不可绕过——只要它开着，所有其他措施都只是给攻击者多加几秒时间而已。每次改完 sshd_config，别忘了用 sudo sshd -t 检查语法，再 sudo systemctl reload sshd 平滑重启，避免连接中断。
