无注释SSH公钥如何溯源归属?

一台运行了几年的服务器，authorized_keys 里往往躺着几行注释字段空着的公钥。它们可能依然能登录，却没人说得清是谁的。这类密钥是溯源中最麻烦的部分：不能随手删，也没法直接确认归属。

先固定身份，再找使用痕迹

溯源的第一步不是猜人，而是把每把密钥变成可稳定引用的对象。注释字段可以被随手改写，同名不同钥的情况也不罕见，真正可靠的标识是公钥指纹。用 ssh-keygen -lf 对 authorized_keys 中每一行计算指纹并登记，后续所有比对、告警、删除动作都以指纹为准，而不是以注释或文件行号为准。

指纹只回答“这把钥匙是什么”，不回答“谁在用”。接着查使用痕迹：通过 lastlog 或 journalctl 找该密钥对应的登录记录，能看出它大致被哪些来源使用、活跃在什么时间窗口、最后一次使用距今多久。原文的经验是超过 90 天未使用的密钥应标记为待清理，但对无注释密钥，这个信号要反过来读——有近期登录记录的，说明背后有活人在用，删除前必须先找到人；长期沉寂的，反而更像测试遗留或早已废弃的凭据。

外部比对与交叉验证

公钥本身是可公开材料。没有注释的密钥，可以拿去与团队成员本机 ~/.ssh/*.pub 逐个比对，也可以检索 GitHub、GitLab 上公开的 SSH 公钥——不少开发者会把同一把公钥挂到代码托管平台，这往往是最快对上号的路径。需要注意，这类比对只能说明“该公钥曾出现在某人的公开资料中”，不等于此人就是当前持有者，结论仍需人工确认。

还有一个容易忽略的盲区：使用云厂商密钥对功能时，公钥会写入实例的系统配置，控制台的绑定关系与实例内部实际生效的列表可能并不一致。溯源必须以实例内 authorized_keys 的实际内容为准，而不是以控制台显示的状态为准。

溯不到源的如何处置

总会有几把密钥查不到归属。这类密钥的风险评级应当最高：既无法排除它是自动化脚本的残留，也无法排除它是攻击者植入的入口。处置方式不是直接删除，而是先记录指纹、从 authorized_keys 中移除，观察一段时间（原文建议 7 到 14 天）是否出现登录失败或业务异常，确认无影响后再彻底删除。这段观察期配合登录日志监控，如果出现该指纹的失败尝试，说明持有者仍在活动，需要继续追查。

无法溯源本身就是一个结论：它暴露的是密钥登记机制的缺失。把指纹、所属人员或用途、授权主机、创建时间、上次使用时间、风险等级固化成登记表，新公钥一律先登记再授权，无注释密钥才会从常态变成异常。