首页/安全/漏洞与攻击面速查/SSH 弱口令与暴力破解防护
主机与服务风险面53 条

SSH 弱口令与暴力破解防护

SSH(22)是服务器管理的标配入口,弱口令与允许 root 直接登录会放大暴力破解成功率;防护组合为密钥认证、登录限速与来源限制。

漏洞与攻击面速查安全更新于 2026-10-13

SSH 弱口令问题是什么

SSH 是服务器的标准管理入口,也是公网上被自动化尝试最密集的服务之一。风险来自三件事叠加:允许口令认证、口令强度不足、允许高权限账号直接登录。自动化工具用常见用户名与字典口令轮询,一旦命中就等于拿到一台主机的完整控制权,并可据此横向探测内网。因此治理思路是减少口令认证的使用面、把入口限制到可信来源、并对失败尝试做出可观测的响应。

基本信息

服务与端口OpenSSH sshd,默认 22
主要风险口令爆破、撞库、默认口令、高权限账号可直接登录
关键加固项禁用口令认证、禁止 root 登录、限定用户与来源、限制尝试次数
观测位置Debian 系 /var/log/auth.log,RHEL 系 /var/log/secure,或 journalctl -u sshd
典型信号同源大量 Failed password、陌生 IP 的成功登录记录
配套控制fail2ban 或防火墙上限速、堡垒机与多因素认证

典型场景

  • 云主机默认放行 22 给全网来源,运维图方便用口令登录
  • 设备与系统共用同一套简单口令,一处泄露全网复用
  • 离职人员账号未清理,长期保留可用入口
  • 测试机、跳板机沿用生产口令,成为横向移动的起点
  • 只改了端口号,扫描识别后攻击照旧,失败尝试依旧存在
  • 密钥已下发但仍保留口令认证,弱口令通道没有被关闭

加固要点(sshd_config)

加固要点(sshd_config)
PermitRootLogin no                 # 需要运维提权时先登录普通账号再 sudo
PasswordAuthentication no          # 全面转向密钥认证
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy ops              # 只保留必要的登录账号
# 改完先 sshd -t 语法检查,再 reload,保留一个已登录会话避免自锁
# 配合 fail2ban 或防火墙限速封禁高频失败来源

失败登录观察

失败登录观察
grep 'Failed password' /var/log/auth.log | tail -20      # Debian/Ubuntu 系
grep 'Failed password' /var/log/secure | tail -20         # RHEL/CentOS 系
journalctl -u sshd --since '1 hour ago' | grep -i failed
lastb | head                       # 查看失败登录记录
last -n 10                         # 查看近期成功登录来源
# 关注:同源高频失败、陌生地理位置的登录成功记录、非工作时段登录

加固项与风险对照

配置项不做时的风险建议取值
PasswordAuthentication字典攻击可持续尝试no,改用密钥
PermitRootLogin高权限账号直接被尝试no 或 prohibit-password
MaxAuthTries单连接可尝试大量口令3 至 5
AllowUsers / AllowGroups任意账号都可登录尝试白名单必要账号
来源限制全网可达,扫描无成本仅放行管理网段或堡垒机
切到密钥认证前先确保密钥可用,并为关键设备保留带外访问方式(控制台、带外管理口),避免配置失误后无法登录。
fail2ban 的 jail 配置要与系统日志路径对应,并把堡垒机、监控与自动化平台来源加入白名单,否则正常的批量运维会被误封。

密钥落地与生效核对

密钥落地与生效核对
ssh-keygen -t ed25519 -C 'ops@example.com'          # 生成密钥对,私钥加保护口令
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@server   # 下发公钥
ssh -o PreferredAuthentications=publickey deploy@server   # 验证密钥可登录
sshd -T | grep -E 'passwordauthentication|permitrootlogin|maxauthtries'
# 确认顺序:先证明密钥可用,再关闭口令认证,最后 reload 生效
# 重点检查 .ssh 目录权限为 700、authorized_keys 为 600,属主是目标账号

收敛节奏建议

  • 先在堡垒机或跳板机上线来源限制与限速,把暴露面压到最小
  • 再分批推送密钥并验证,确认每个账号都有可用的登录方式
  • 然后关闭口令认证与 root 直登,同时保留一个已登录会话兜底
  • 最后加告警规则:失败次数突增与陌生来源成功登录都进入值班视野

易错点

  • 只改端口号当防护:扫描仍可识别服务,密钥认证与来源限制才是关键控制
  • 禁用口令认证前没有验证密钥可用:一旦密钥或权限目录配错,可能同时失去所有登录途径
  • 允许 root 直接登录:爆破成功后的破坏力与清理难度都显著放大
  • 封禁策略没有白名单:堡垒机与自动化发布被误封会直接造成生产故障
  • 只看失败次数不看成功记录:少量但成功的陌生来源登录才是最高优先级的告警
  • 多台主机共用同一密钥且无口令保护:私钥泄露等于批量失守,应按角色分密钥并给私钥加保护

数据来源与参考

  • OpenSSH 官方手册(sshd_config 5)
  • fail2ban 官方文档
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌