应逐个检查所有用户（含系统账户）的 authorized_keys 文件，重点排查异常行数、陌生邮箱、无注释公钥、可疑指纹及登录日志匹配情况，并清洗后比对哈希，避免误报。
检查所有用户的 authorized_keys 文件是否被篡改
攻击者一旦获得低权限账户（如普通用户或被爆破成功的账号），第一件事常是往其 ~/.ssh/authorized_keys 里追加自己的公钥，实现长期免密登录。这个文件本身不记录修改时间，且权限宽松时容易被覆盖，所以不能只看“有没有改动”，而要看“有没有不该有的内容”。
- 逐个检查所有可登录用户的
authorized_keys：用find /home -name authorized_keys -path "*/.ssh/*" 2>/dev/null找出路径，再对每个结果执行cat $file | grep -v "^#" | sed '/^$/d' | wc -l统计有效公钥行数——正常用户通常只有 1–3 行，若发现某用户有 10+ 行，尤其包含陌生邮箱或无注释的长字符串，高度可疑 - 特别注意
/root/.ssh/authorized_keys：即使你没配 root 免密，也要查；有些攻击脚本会直接写入 root 目录，且因权限问题（如cp: Permission denied）可能失败但留下痕迹，需用sudo ls -l /root/.ssh/确认是否存在、是否可读 - 对比可信备份：如果你有历史备份（比如 Git 管理的配置仓库），用
diff -u backup_authorized_keys current_authorized_keys快速定位新增行；没有备份就重点看每行末尾的注释字段（如user@host），陌生 host 名或随机字符串（如ubuntu@ip-172-31-xx-xx）大概率是攻击者留的
识别公钥是否来自已知可信来源
公钥本身是明文，但无法靠肉眼判断是否恶意。关键不是“它长得像不像”，而是“它该不该在这儿”。
- 提取所有公钥的指纹做比对：
ssh-keygen -lf ~/.ssh/authorized_keys会输出每行公钥的 SHA256 指纹和类型（ssh-ed25519或ssh-rsa），把输出存为fingerprints.txt，再跟你自己生成的私钥对应指纹（ssh-keygen -lf ~/.ssh/id_ed25519）逐条核对 - 过滤掉已知无效或过期密钥：旧项目用的
ssh-rsa密钥在 OpenSSH 8.8+ 默认被禁用，如果sshd_config已升级但authorized_keys里还留着大量ssh-rsa公钥，它们虽不能登录，却可能是攻击者早期植入、尚未清理的残留 - 警惕空注释或无注释公钥：合法运维团队一般会在公钥末尾写明用途（如
jenkins-deploy@ci或alice-laptop@macbook），纯公钥末尾为空或只有随机字符（如4x9zQm）基本可判定为恶意
结合登录日志反向验证可疑公钥是否被实际使用
光看 authorized_keys 不够，得确认这些公钥是不是真被用来登过系统。很多后门公钥长期闲置，但只要存在，就是风险敞口。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 查
/var/log/auth.log（Debian/Ubuntu）或/var/log/secure（RHEL/CentOS）中近期的Accepted publickey记录：grep "Accepted publickey" /var/log/auth.log | tail -20 - 把日志里出现的用户名和 IP 提取出来，跟
authorized_keys所在路径交叉验证：比如日志显示Accepted publickey for alice from 203.0.113.5，那就去查/home/alice/.ssh/authorized_keys，看里面是否有对应指纹的公钥；若日志有记录、但该用户文件里没这公钥，说明可能被动态加载（如通过AuthorizedKeysCommand），需进一步查sshd_config - 注意时间偏差：攻击者常选业务低峰期登录（如凌晨 2–4 点），用
awk '$0 ~ /Accepted publickey/ && $3 ~ /(root|admin|deploy)/ {print $1,$2,$3,$9,$11}' /var/log/auth.log | sort快速筛出高危账户+异常时段组合
自动化扫描脚本的关键检查点
手动排查适合单台服务器，批量管理时建议用脚本，但必须避开几个常见误报陷阱：
- 不要只依赖
ls -la ~/.ssh判断权限：攻击者可能把authorized_keys改成 644 权限，但服务端仍能读取；真正要盯的是~/.ssh目录是否为 700、家目录是否被组写（stat -c "%a %n" ~输出不能是 775/777） - 避免用
cat authorized_keys | md5sum做完整性校验：文件末尾可能被追加空行或注释，导致哈希值变但内容无实质变化；应先用sed '/^[[:space:]]*#/d; /^[[:space:]]*$/d' authorized_keys | sha256sum清洗后再比对 - 忽略
.ssh/下的非常规文件：有些后门会新建.ssh/authorized_keys2或.ssh/config.bak并诱导管理员误操作，find /home -path "*/.ssh/*" -type f ! -name "authorized_keys" -name "*.pub" -o -name "id_*" 2>/dev/null可辅助发现异常文件
最易被忽略的一点：攻击者添加的公钥可能不在你常规管理的用户下，而是在一个你早已遗忘的测试账户、CI 机器人账户，甚至 nobody 或 daemon 这类系统账户的 home 目录里——这些路径默认不被 find /home 覆盖，得额外加 getent passwd | awk -F: '$3 >= 1000 && $6 != "/nonexistent" {print $6}' | xargs -I{} find {} -path "*/.ssh/authorized_keys" 2>/dev/null 才能扫全。
