实际使用与边界
适用场景：保留一份简短诊断记录：目标主机、账户、实际提供的身份、有效 AuthorizedKeysFile、关键权限，以及证明修复成功的服务器日志行。
边界：不同操作系统和 sshd 配置的命令与权限要求可能不同。一次只改一个条件，并保留恢复路径。
先分类错误
超时或 connection refused 不是公钥认证问题；主机密钥警告也不是 authorized_keys 问题。Permission denied (publickey) 通常表示服务器已到达，但拒绝了当前认证方式或凭证。先分层能避免随机改权限或重复生成密钥。
确认客户端提供了正确密钥
第一次测试使用明确的 IdentityFile 和 ssh -v 或 ssh -vv，查看实际加载和提供的身份。ssh-agent、多个 config 区块、别名和默认密钥都可能让客户端尝试另一把钥匙。确认成功后再简化配置，避免无关身份过多。
比较派生出的公钥
在可信机器上从私钥导出公钥，与服务器目标账户 authorized_keys 中的完整 OpenSSH 公钥行比较。算法前缀也重要：ssh-ed25519 不会匹配 ECDSA 或 RSA。末尾注释通常只是标签，但密钥材料必须完整且位于同一行。
检查服务器读取的路径
确认目标账户、home 目录、.ssh 目录和 authorized_keys 路径。放在 /root 下的公钥不能授权另一个用户。还要检查 sshd 的有效 AuthorizedKeysFile 和 include 配置，不要默认服务器使用标准路径。
修权限，但不要削弱安全性
客户端私钥只应由所有者读取；服务器端 .ssh 和 authorized_keys 不应被无关用户写入，home 路径也要符合 StrictModes 检查。使用系统文档要求的所有者和模式，不要把整个 home 或 authorized_keys 改成 world-writable。
最后检查账户策略和日志
如果密钥、路径和权限都正确，检查有效 sshd 配置、目标 shell、账户锁定或过期状态、AllowUsers、AllowGroups 以及服务器认证日志。一次只改一个条件，并保留能证明结果的日志行。
结论
大多数公钥认证失败都可以按五个问题定位：是否到达预期服务器、服务器是否提供了预期主机密钥、客户端是否提供了正确私钥、服务器是否读取了匹配公钥，以及账户策略是否允许认证。按层排查比不断重建凭证更安全，也更容易留下可复核证据。
常见问题
文件存在，为什么仍然提示 publickey？
路径存在只说明文件存在。客户端可能拒绝其格式、提供了另一把密钥，或服务器没有为当前账户安装匹配公钥。
authorized_keys 末尾的注释重要吗？
通常只是标签，不影响认证；算法和密钥材料必须完整。
应该马上生成新密钥吗？
通常不应马上生成。先确认客户端实际提供的密钥并与服务器记录比较；只有旧密钥丢失、暴露或需要轮换时才生成替代品。