海外服务器遭遇可疑登录尝试后，账号、SSH日志和防火墙策略应如何复核
面向运维工程师，说明海外服务器出现异常登录尝试后如何通过SSH认证日志、账号与密钥、防火墙规则判断风险，并给出访问入口加固和持续审计建议。
风险范围先定清：可疑登录不等于已入侵，但不能只看一条告警
海外服务器暴露在公网后，SSH 端口出现来自陌生 IP 的登录尝试并不少见。真正需要立即确认的是：这些尝试是否只是被拒绝的扫描，还是已经出现成功登录、弱口令命中、异常账号活动或防火墙放行范围过宽。处理时应以“保留现有会话、先查证再变更”为原则，避免在未确认远程控制台可用的情况下修改 SSH 或防火墙导致自己被锁在服务器外。
以下操作默认面向 Linux 服务器，并且你已拥有合法管理员权限。不同发行版的 SSH 认证日志路径可能不同：Debian/Ubuntu 通常在 /var/log/auth.log，RHEL/CentOS/Rocky/AlmaLinux 通常在 /var/log/secure，使用 systemd-journald 的系统也可以通过 journalctl 查看。若服务器由云平台托管，还要同步核对安全组、ACL 或边界防火墙，因为系统内防火墙并不一定代表最终访问入口。
从日志判断风险等级：重点看失败、成功和来源变化
SSH日志是确认可疑登录风险的第一入口。不要只统计失败次数，更要关注是否出现了成功登录、登录用户是否合理、来源 IP 是否与运维出口一致、时间点是否匹配正常变更窗口。
先定位 SSH 认证日志位置
可以先按发行版检查日志文件，再用 journalctl 补充确认：
# Debian / Ubuntu 常见路径
sudo grep -Ei "sshd|failed|accepted|invalid user" /var/log/auth.log | tail -n 100
# RHEL / CentOS / Rocky / AlmaLinux 常见路径
sudo grep -Ei "sshd|failed|accepted|invalid user" /var/log/secure | tail -n 100
# systemd 日志方式，适用于多数现代 Linux
sudo journalctl -u ssh -u sshd --since "24 hours ago" --no-pager
如果日志已经轮转，可查看压缩日志：
sudo zgrep -Ei "sshd|failed|accepted|invalid user" /var/log/auth.log* | tail -n 100
sudo zgrep -Ei "sshd|failed|accepted|invalid user" /var/log/secure* | tail -n 100
关注几类关键日志含义
| 日志特征 | 风险判断 | 处理重点 |
|---|---|---|
Failed password |
密码登录失败，常见于扫描或撞库 | 判断频率、来源、目标账号 |
Invalid user |
对不存在账号尝试登录 | 通常是自动化扫描，但需确认是否持续高频 |
Accepted password |
密码登录成功 | 高风险，需确认来源和账号是否可信 |
Accepted publickey |
密钥登录成功 | 不一定异常，需核对密钥归属和登录来源 |
authentication failure |
认证失败记录 | 结合用户、IP、时间段分析 |
session opened / session closed |
会话打开或关闭 | 用于确认登录是否形成有效会话 |
如果只看到大量 Invalid user 和 Failed password，且没有成功登录记录，通常说明服务器被扫描，但入口仍需加固。如果出现非预期的 Accepted password 或 Accepted publickey，应按疑似入侵处理：先保留日志、保留当前连接、确认业务影响，再进行账号、密钥和凭据轮换。
快速筛选成功登录记录
# Debian / Ubuntu
sudo grep -Ei "Accepted password|Accepted publickey" /var/log/auth.log*
# RHEL 系
sudo grep -Ei "Accepted password|Accepted publickey" /var/log/secure*
# journald
sudo journalctl -u ssh -u sshd --since "7 days ago" --no-pager | grep -Ei "Accepted password|Accepted publickey"
同时查看近期登录历史：
last -a | head -n 30
lastlog | head -n 30
who
w
last 记录依赖 /var/log/wtmp，lastlog 记录用户最近登录时间。它们可以辅助判断，但不应作为唯一证据；如果系统已被深度入侵，本地日志存在被篡改的可能，后续应结合远程日志、堡垒机记录或云平台登录审计。
复核账号与密钥：确认有没有异常入口被留下
SSH 登录最终落到系统账号和认证材料上。可疑登录出现后，账号安全检查不要只改 root 密码，而要核对所有可登录账号、sudo 权限、SSH 密钥和系统配置。
检查可交互登录账号
先查看哪些账号拥有可登录 Shell：
awk -F: '$7 ~ /(bash|sh|zsh|ksh)$/ {print $1,$3,$6,$7}' /etc/passwd
重点关注：
- 是否存在不认识的普通用户；
- UID 是否异常，尤其是 UID 为
0的非 root 账号； - 业务账号是否被赋予交互式 Shell；
- 临时运维账号是否过期后仍保留；
- 是否有账号近期登录时间与运维记录不匹配。
检查 UID 为 0 的账号：
awk -F: '$3 == 0 {print $1,$3,$6,$7}' /etc/passwd
正常情况下只有 root 使用 UID 0。如果出现其他账号，应立即确认来源。
检查 sudo 和管理组权限
不同发行版的管理组名称不同。Debian/Ubuntu 常见为 sudo，RHEL 系常见为 wheel：
getent group sudo
getent group wheel
sudo grep -R "^[^#].*ALL" /etc/sudoers /etc/sudoers.d/ 2>/dev/null
这里不建议直接删除 sudo 配置。更安全的做法是先记录当前配置、确认业务依赖，再禁用不应拥有管理权限的账号。涉及 /etc/sudoers 的修改应使用 visudo，避免语法错误导致管理员权限不可用。
检查 SSH 公钥文件
重点查看 root 和运维账号的 authorized_keys：
sudo find /root /home -path "*/.ssh/authorized_keys" -type f -print -exec ls -l {} \;
进一步查看密钥内容时，应核对备注、指纹和归属，不要只看文件是否存在：
sudo ssh-keygen -lf /root/.ssh/authorized_keys
如果某个用户的 authorized_keys 中存在无法确认来源的公钥，应先备份该文件，再移除异常条目，并记录操作时间。不要直接清空整个文件，避免影响正常运维入口。
同时检查 SSH 目录权限。常见建议为：
# 仅查看，不直接修改
sudo ls -ld /root/.ssh /home/*/.ssh 2>/dev/null
sudo ls -l /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys 2>/dev/null
一般情况下，用户家目录不应对其他用户可写，.ssh 目录通常为 700，authorized_keys 通常为 600 或更严格。权限过宽可能导致密钥被非预期用户修改。
复核 SSH 登录限制：优先减少暴露面
确认账号状态后，应检查 SSH 服务配置。配置文件通常为 /etc/ssh/sshd_config，部分系统还会使用 /etc/ssh/sshd_config.d/*.conf 目录拆分配置。修改前建议备份并先做语法检查。
sudo sshd -T | grep -Ei "port|permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication|maxauthtries|allowusers|allowgroups"
sshd -T 会输出最终生效配置，比单独查看配置文件更接近实际状态。重点关注以下项：
| 配置项 | 建议方向 | 说明 |
|---|---|---|
PermitRootLogin |
优先关闭 root 远程登录或限制为密钥 | 先确保有普通管理账号和 sudo 权限 |
PasswordAuthentication |
能使用密钥时建议关闭密码登录 | 关闭前必须验证密钥登录可用 |
PubkeyAuthentication |
通常保持启用 | 便于使用密钥替代密码 |
KbdInteractiveAuthentication |
按需关闭 | 避免绕过密码登录限制的误配置 |
AllowUsers / AllowGroups |
限定可登录用户 | 适合账号较少的服务器 |
MaxAuthTries |
适当降低 | 减少单连接尝试次数 |
示例配置片段如下，仅作为方向，不能直接覆盖现有文件：
# /etc/ssh/sshd_config 或 /etc/ssh/sshd_config.d/hardening.conf
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3
AllowUsers opsuser
变更前务必确认 opsuser 已能通过密钥登录并具备必要的 sudo 权限。修改后先检查语法：
sudo sshd -t
再重载服务。不同发行版服务名可能是 ssh 或 sshd：
sudo systemctl reload sshd
# 如果提示服务不存在，再核对：
sudo systemctl reload ssh
重载后不要关闭当前 SSH 会话，另开一个终端测试新连接，确认可登录后再退出旧会话。
防火墙策略复核：系统防火墙和云侧安全组要一起看
海外服务器的 SSH 可疑登录往往来自公网大范围扫描。只在系统里限制端口还不够，如果云平台安全组仍对全网开放，攻击流量仍会到达服务器。反过来，如果安全组已经限制来源，系统内防火墙可能看不到完整风险。
先查看当前放行面
常见防火墙查看命令如下，按实际系统选择：
# UFW，常见于 Ubuntu
sudo ufw status verbose
# firewalld，常见于 RHEL 系
sudo firewall-cmd --list-all
# nftables
sudo nft list ruleset
# iptables
sudo iptables -S
复核时重点看：
- SSH 端口是否对
0.0.0.0/0或::/0开放； - 是否存在多个 SSH 端口同时开放；
- IPv6 是否被忽略，导致 IPv4 限制了但 IPv6 仍开放；
- 云安全组、系统防火墙、面板防火墙是否规则不一致；
- 运维出口 IP 是否固定，是否适合做白名单。
优先采用来源限制，而不是只依赖改端口
更改 SSH 端口可以减少低质量扫描噪声，但不能作为核心防护。更可靠的策略是只允许可信办公出口、堡垒机、VPN 或跳板机访问 SSH。
以 UFW 为例，调整前应先确认当前会话来源 IP，并优先添加允许规则，再收紧默认访问：
# 示例：仅允许可信运维出口访问 22 端口
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
# 确认规则存在后再评估是否移除全网放行规则
sudo ufw status numbered
以 firewalld 为例，可使用 rich rule 进行来源限制：
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port protocol="tcp" port="22" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-all
上述 IP 203.0.113.10 是文档示例地址，实际应替换为你的运维出口、堡垒机或 VPN 出口。若运维人员经常跨地区办公，直接使用个人动态 IP 白名单可能维护成本较高，应考虑 VPN、零信任接入或堡垒机统一入口。
在执行防火墙变更前，建议具备以下条件：
- 已确认云平台控制台或远程救援模式可用；
- 当前 SSH 会话保持不断开；
- 已备份当前防火墙规则；
- 已准备回滚命令或可通过控制台恢复；
- 已同步修改 IPv4 与 IPv6 规则。
备份示例：
# iptables 规则备份
sudo iptables-save > ~/iptables-backup-$(date +%F-%H%M).rules
# nftables 规则备份
sudo nft list ruleset > ~/nftables-backup-$(date +%F-%H%M).rules
验证加固是否生效：看连接结果，也看日志变化
完成账号、SSH 配置和防火墙策略调整后，需要验证“该拒绝的拒绝、该允许的允许”。验证不是简单地能连上就结束，还要看日志是否按预期记录。
建议按以下顺序检查：
- 从可信来源新建 SSH 连接，确认管理账号可登录；
- 确认 root 远程登录是否按配置被拒绝；
- 确认密码登录是否已禁用，密钥登录是否正常；
- 从非白名单来源测试 SSH 是否无法建立连接；
- 查看认证日志，确认拒绝原因符合预期；
- 查看防火墙命中记录或云安全组流量记录。
可用以下命令观察实时日志：
# Debian / Ubuntu
sudo tail -f /var/log/auth.log
# RHEL 系
sudo tail -f /var/log/secure
# journald
sudo journalctl -u ssh -u sshd -f
如果修改后出现正常账号无法登录，应优先通过现有会话或控制台恢复配置。不要连续盲目重启 SSH 服务，否则可能扩大影响。若 sshd -t 已提示配置错误，应先修正语法再重载。
出现成功可疑登录时，应按更高等级处置
如果 SSH日志中已经出现无法解释的 Accepted password、Accepted publickey 或异常会话记录，不能只把防火墙收紧当作结束。此时应假设账号凭据可能泄露，并评估服务器上业务数据、配置文件、密钥、数据库连接串和第三方 Token 是否暴露。
建议动作包括：
- 立即保存相关日志副本，避免轮转覆盖；
- 记录异常登录账号、来源 IP、时间段和执行痕迹；
- 检查该账号的 Shell 历史、计划任务和启动项；
- 轮换该账号密码、SSH 密钥及相关业务密钥；
- 核对
/etc/crontab、/etc/cron.*、用户 crontab； - 检查 systemd 自启动服务是否有异常项；
- 对关键业务进行完整性校验；
- 必要时从可信备份重建服务器，而不是在不可信系统上继续修补。
相关检查示例：
sudo crontab -l
sudo ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.weekly
sudo systemctl list-unit-files --type=service --state=enabled
sudo ss -tunlp
这些命令用于发现异常持久化和监听服务，不应代替完整的安全取证。若服务器承载核心业务或敏感数据，建议保留磁盘快照后再进行深入分析，避免清理动作破坏证据。
将可疑登录处置固化为持续审计
单次加固只能降低当前暴露面，不能保证以后不再出现可疑登录。海外服务器面向公网运行时，应把账号安全、SSH日志和防火墙策略纳入持续审计。
可落地的审计项包括：
- 每周检查一次成功登录记录，重点关注非办公时间和陌生来源；
- 对管理员账号建立清单，离职、转岗或外包结束后及时回收；
- 定期核对
authorized_keys指纹，避免遗留临时密钥； - 将 SSH 认证日志转发到独立日志平台，减少本机日志被篡改的影响；
- 对短时间大量失败登录设置告警；
- 使用 Fail2ban、sshguard 或等效工具做自动封禁，但不要替代白名单策略；
- 为关键服务器引入堡垒机、VPN 或多因素认证；
- 定期演练防火墙回滚和控制台救援流程。
Fail2ban 这类工具适合降低暴力尝试频率，但它依赖日志匹配和封禁规则，不能宣称百分百防御。若 SSH 已通过安全组限制到固定入口，Fail2ban 的价值主要体现在二次防护；若 SSH 仍对公网开放，则应优先收紧访问来源。
最后保留一份服务器访问基线：哪些账号允许登录、哪些 IP 可以访问 SSH、SSH 配置关键项是什么、日志保留多久、告警由谁处理。下次再出现海外服务器可疑登录时，就能快速判断是普通扫描、配置偏差，还是已经触及账号安全边界，并按既定流程响应。