authorized_keys 为什么是重点
authorized_keys 决定哪些公钥可以直接登录某个账号，写进去一行就等于开了一把新钥匙。攻击者拿到权限后最省事的持久化方式，就是往这里追加自己的公钥：不需要密码、不受口令轮换影响、与正常运维密钥混在一起很难一眼看出。排查时逐条核对指纹、注释内容与行首选项（command=、from= 等限制），并与认证日志里的登录指纹一一对应，才能确认哪些条目是被引入的。
基本信息
| 路径 | ~/.ssh/authorized_keys；root 为 /root/.ssh/authorized_keys |
|---|---|
| 配置项 | sshd_config 的 AuthorizedKeysFile 决定实际路径，默认 .ssh/authorized_keys |
| 文件权限 | 目录 700、文件 600，StrictModes 开启时权限过松会导致密钥被拒绝 |
| 行首选项 | command=""、from=""、no-pty、no-agent-forwarding、restrict |
| 指纹核对 | ssh-keygen -lf 计算 SHA256 指纹，与 auth 日志中的指纹比对 |
| 其他位置 | AuthorizedKeysCommand、部分发行版的集中密钥目录需一并检查 |
典型使用场景
- 确认某账号是否被追加了外部公钥（持久化排查核心步骤）
- 核对日志中 publickey 登录所用的指纹对应哪一行密钥
- 审计密钥来源：注释字段常包含邮箱或主机名，可判断归属
- 检查是否存在无限制密钥——缺少 from= 与 command= 限制的条目风险更高
- 清理离职或过期人员的密钥，同时保留业务必需密钥
- 与其他持久化点（cron、systemd、LD_PRELOAD）交叉确认
清单与指纹核对
清单与指纹核对
# 先看文件属性：mtime 可被 -p 复制等方式伪造，仅作参考
ls -la --time-style=full-iso /root/.ssh/ /home/*/.ssh/ 2>/dev/null
# 逐行查看密钥内容与注释（注释在行尾）
nl -ba /root/.ssh/authorized_keys
# 计算 SHA256 指纹，与认证日志里记录的指纹比对
ssh-keygen -lf /root/.ssh/authorized_keys -E sha256
# 认证日志中公钥登录会带指纹，可直接搜索
# 形如：Accepted publickey for root from 1.2.3.4 ... ssh2: RSA SHA256:xxxx
grep 'Accepted publickey' /var/log/auth.log | tail -20
# 统计全系统密钥条目，找出最近被加入的账号
find /root /home -maxdepth 3 -name authorized_keys -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | sort密钥行逐段读法
| 字段 | 含义 | 判读要点 |
|---|---|---|
| 行首选项 | command=/from=/restrict 等限制 | 无任何限制的条目风险最高，可从任意来源登录 |
| 算法与密钥体 | ssh-rsa、ssh-ed25519、ecdsa 等 | ssh-rsa 沿用旧算法，新建密钥倾向 ed25519 |
| 注释字段 | 行尾说明信息 | 常含邮箱与主机名，可判断归属；空白注释需重点核查 |
| 指纹 | ssh-keygen 输出的 SHA256 | 与日志指纹必须一一对应，对不上说明有未记录的密钥 |
| 文件属主与权限 | 目录 700、文件 600 | 权限过松会导致密钥失效，也可能被其他用户读取 |
改动前先备份并逐条记录原始内容与哈希：误删业务密钥会造成运维中断，改动后无法还原原始状态也会影响证据完整性。确认后按行删除而不是整文件覆盖。
除了 authorized_keys，还要看 ~/.ssh/ 下的 config、known_hosts 与私钥文件，以及 sshd_config 是否把 AuthorizedKeysFile 指到了自定义路径或启用了 AuthorizedKeysCommand。