同一台服务器昨天还能用密钥登录，今天客户端却回退到密码；密码输入后又能正常进入。这至少证明网络、SSH端口和账号密码认证仍然可用，故障范围可以先收窄到公钥认证路径。
最重要的安全动作是保留当前已经登录的管理员会话，在密钥恢复并用新窗口验证前不要退出。不要为了省事关闭 StrictModes、开放root密码登录或重写整个SSH配置，这些操作会扩大暴露面。
先用客户端调试确认密钥有没有被提供
在客户端执行详细调试，并显式指定目标私钥：
ssh -vvv -i ~/.ssh/id_ed25519 user@server_ip调试信息可以看到客户端读取了哪些配置、准备提供哪把密钥，以及服务器是否接受。日志中包含主机、用户名和本地路径，分享前应先脱敏。
没有出现目标密钥时，应检查 -i 路径、~/.ssh/config、密钥代理和当前用户环境。已经提供但服务端拒绝，则重点转到服务端日志、对应账号和授权文件。
服务端日志决定下一步
在保留的密码会话中，一边观察认证日志，一边从另一个窗口重试密钥登录：
sudo journalctl -u ssh -f
sudo journalctl -u sshd -fDebian、Ubuntu与RHEL系服务单元名称可能不同，也可以检查发行版对应的认证日志。只执行其中真实存在的服务，不要因命令报找不到单元就误判SSH没有日志。
日志可能提示授权文件权限或属主错误、账号不允许、公钥算法不匹配、密钥已撤销，或根本没有找到授权键。先依据服务器给出的拒绝原因分支，不要直接重新生成所有密钥。
确认实际登录账号和家目录
公钥写在A账号的 authorized_keys 中，却使用B账号连接，是很常见的低级错位。先在服务器确认目标账号和系统记录的家目录：
getent passwd user
sudo -u user sh -c 'printf "%s\n" "$HOME"'云镜像的默认账号可能是 ubuntu、debian、rocky 或其他名称，不能只凭系统发行版猜测。账号被锁定、Shell被设置为不可登录，或者家目录挂载异常，也会改变认证结果。
跳板机、堡垒机和SSH别名还可能让客户端连到不同主机。应对照服务端主机指纹和地址，确认修改的是实际接收连接的服务器。
读取sshd真正生效的配置
配置可能分散在主文件、include目录和Match规则中。先测试语法，再查看目标用户、地址和主机条件下的有效值：
sudo sshd -t
sudo sshd -T -C user=user,addr=client_ip,host=server | grep -E 'pubkeyauthentication|authorizedkeysfile|strictmodes|authenticationmethods'替换真实用户、客户端地址和主机名。AuthorizedKeysFile 可以是相对家目录的路径，也可以被改成集中存储路径；只检查默认的 ~/.ssh/authorized_keys 可能看错位置。
还要留意 Match 规则、AuthenticationMethods、证书认证和外部 AuthorizedKeysCommand。修改前先确认是哪条规则生效，避免删除与其他用户有关的配置。
权限和属主应该精确核对
OpenSSH的 StrictModes 默认会检查用户文件和家目录的属主与模式。可用下面的命令查看整条路径：
namei -l /home/user/.ssh/authorized_keys
stat -c '%U %G %a %n' /home/user /home/user/.ssh /home/user/.ssh/authorized_keys常见思路是家目录不能被无关用户写入，.ssh 和 authorized_keys 应由目标用户拥有并限制权限。实际路径和安全策略可能不同，应以服务端日志及生效配置为准。
不要对整个家目录递归执行chmod或chown。 这可能破坏网站、面板和应用文件权限。只修正确认错误的目录或文件，并记录原值。
核对公钥内容而不是复制私钥
在客户端从私钥导出公钥指纹，再与服务器授权文件中的目标键比较：
ssh-keygen -lf ~/.ssh/id_ed25519
ssh-keygen -y -f ~/.ssh/id_ed25519 | ssh-keygen -lf -服务器上的 authorized_keys 每行应包含完整公钥记录。复制过程中断行、前缀缺失或粘贴了另一把公钥，都会导致拒绝。私钥始终保留在客户端，不要上传到服务器，也不要发送给客服。
密钥行前还可能带来源地址、强制命令等限制选项。服务器地址或访问路径变化后，这些限制会让同一把密钥不再适用，需要根据安全设计调整，而不是全部删除。
算法兼容和升级变更要有证据
客户端或服务端升级后，旧算法可能不再默认接受。调试日志通常会显示算法协商或签名被拒绝，先确认密钥类型和双方版本，再制定替换计划。
长期方案应生成当前支持的密钥并逐步替换旧密钥。临时重新启用弱算法会降低安全性，只能在明确风险、限定来源并设定移除时间的情况下评估，不能作为默认修复。
旧服务器的SSH配置经过多次面板修改和账号迁移后，准备重建时可以在 萤光云 复现同版本配置，也可以用按小时计费的 LightNode 建立短期对照环境。只复制公钥与明确的安全规则，不要把私钥或整份来源不明的旧配置带入新服务器。
平滑重载并完成双窗口验收
配置有修改时先执行 sshd -t，确认没有语法错误，再通过发行版对应服务进行reload。保留旧会话，在新窗口使用目标密钥测试，确认能登录到正确账号。
验收还应检查服务端日志不再出现权限或算法拒绝，密码认证策略保持原计划，没有因为排查临时开放额外入口。最后再重启一次SSH服务或在维护窗口重启服务器，确认授权路径和配置仍然生效。
只有新会话稳定使用目标密钥登录、旧的临时放宽措施已经撤销，并且密码或其他备用方式符合既定安全策略，才算故障关闭。
