直接答案：先保存认证日志、当前会话、账号、密钥、sudo和服务变更，区分大量失败尝试与真实成功登录。若确认未知成功会话，应从可信控制台隔离并按安全事件处理；若只是爆破噪声，优先限制管理来源、使用独立密钥、关闭不必要口令和root远程登录，再用Fail2ban等作补充。每次改sshd前运行语法检查并保持第二会话。
本文于 2026 年 9 月按官方文档核对。命令和配置只展示判断方法，不代表可在任意生产环境直接复制；发行版、云平台、网络拓扑和业务写入不同，执行前必须确认对象、权限、备份和带外恢复入口。
专属资产：不锁死自己的分阶段加固流程
| 现象/阶段 | 要判断什么 | 需要的证据 | 安全边界 |
|---|---|---|---|
| 大量Failed password | 尝试不等于成功 | 来源、账号、频率 | 限速与来源控制 |
| Accepted未知登录 | 可能已入侵 | 时间、IP、密钥、命令 | 隔离并保全证据 |
| 新authorized_keys | 持久化入口 | 所有用户密钥与时间 | 先复制证据再吊销 |
| sudo/新用户 | 权限提升 | auth日志、账号文件 | 核对变更来源 |
| 陌生进程/外连 | 后渗透活动 | 进程、网络、启动项 | 评估重装而非只删进程 |
这张表要求每个结论至少有两个相互独立的证据，例如“服务监听+外部连接”“设备延迟+业务耗时”“备份文件+隔离恢复”。单一控制台绿灯、单次截图或一个User-Agent都可能误导，不能作为完成依据。
为什么常见的一键处理容易失败
运维问题通常跨越控制台、操作系统、应用和外部依赖。重启、全放行、清缓存或重装会改变多个变量，并可能清掉最有价值的现场。正确顺序是先定时间线和影响范围，再确认最靠近故障的证据层，最后做可回滚的最小动作。
对于有数据库、订单、表单、队列或用户上传的站点，还要先判断当前是否仍在写入。回滚旧快照、切回旧主机或恢复旧数据库前，必须处理变更期间的新数据；否则技术状态恢复了，业务数据却可能倒退。
六步安全执行流程
1. 确认对象与基线
记录时间和影响，复制认证日志、last/lastlog、当前连接、用户、authorized_keys、sudo与sshd配置；日志先离线保存并校验。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
2. 保留恢复入口
核对成功而非只看失败：未知Accepted、异常账号、非工作时间、密钥变化和命令历史共同判断；User-Agent在SSH中不存在，不能类比Web爬虫。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
3. 取得直接证据
若确认入侵，从控制台限制网络并轮换受影响凭据；不要在可能被控制的主机上继续输入更多生产秘密。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
4. 只做最小变更
建立并验证普通管理员密钥入口，限制来源CIDR或VPN；确认第二会话和带外控制台后，再关闭不必要口令与root远程。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
5. 验证业务与副作用
配置Fail2ban或等价限速，明确日志路径、阈值、封禁时间和白名单；它不能替代补丁、密钥和网络最小暴露。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
6. 重启或跨峰复验
重启或reload sshd前做配置语法检查；从授权与未授权网络分别测试，并持续监控成功登录、配置变更和重复来源。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
不应直接照做的五种处理
- 看到失败日志就宣布服务器已被攻破
- 新密钥未验证就关闭旧入口
- Fail2ban白名单写错锁死管理员
- 只删除陌生进程不查持久化
- 在疑似失陷主机输入新密码
这些做法并非永远错误，而是缺少适用条件。若确需执行，应在变更单中写清目标、影响范围、停止阈值、备份位置、回滚命令和预计恢复时间；高风险动作先在副本或小流量上演练。
回滚触发与数据边界
出现核心写入失败、持续5xx、管理员入口丢失、数据校验不一致、尾延迟越过停止阈值或监控失明时，应停止继续扩大变更。回滚前确认新旧环境各自产生了哪些写入，保留日志和配置差异；回滚后用相同请求和同一时间窗口重测，而不是只看首页恢复。
如果故障根因尚未确认但必须先恢复服务，可以采用限流、摘除单节点、恢复上一配置或临时切流等缓解措施，并明确它只是临时处置。恢复后仍要完成根因分析和复发验证，不能把“重启后正常”写成最终原因。
验收清单
- [ ] 日志证据已离线保存
- [ ] 成功登录均可解释
- [ ] 账号密钥已盘点
- [ ] 管理来源受限
- [ ] 口令/root策略符合预期
- [ ] Fail2ban有测试记录
- [ ] 第二入口和控制台可用
- [ ] 未知持久化已排除或重装
验收应由另一位维护者按记录复现至少一项关键检查，并覆盖重启、真实高峰或等价受控负载。所有失败项都记录实际值与时间，不使用“基本正常”“应该没问题”作为关闭条件。
相关资料与隔离测试入口
站内可继续参考SSH连接不上排查、Linux安全加固、日志保留。需要搭建副本验证配置时，可查看美国轻量云和美国弹性云服务器的实时规格；先确认库存、价格和适用条件，不把测试环境当备份或生产容灾。
常见问题
每天很多Failed password算被入侵吗？
不等于。公网SSH常见自动扫描；关键是是否有未知Accepted、账号/密钥变更、异常进程和外连。
改SSH端口有用吗？
能减少部分无差别噪声，但不是身份安全。仍需密钥、来源限制、补丁、监控和最小权限。
Fail2ban能防所有暴力破解吗？
不能。分布式低频攻击、密钥泄露和应用漏洞不依赖高频失败；它只是速率控制的一层。
能否直接关闭密码登录？
应先验证至少一个密钥管理员和带外恢复入口，再关闭。自动化、备份或旧账号依赖也要盘点。
确认未知成功登录后只改密码够吗？
通常不够。攻击者可能增加密钥、用户、任务或服务，应隔离、取证、轮换外部凭据，并依据可信度决定从干净镜像重建。