TG咨询
SSH密钥登录服务器失败，未必是网络故障。很多问题来自登录用户错误、私钥格式不兼容，或服务器拒绝读取权限不合规的文件。排查时应先确认身份和文件，再查看服务日志，不要一开始就反复生成密钥。
先确认连接对象与登录用户
同一台主机可能存在root、ubuntu、debian或应用专用账户。SSH客户端使用的用户名不同，服务器读取的家目录和authorized_keys位置也不同。以登录用户为ubuntu的主机为例，连接命令通常是：ssh -i ~/.ssh/work_ed25519 ubuntu@203.0.113.20。示例中的地址仅用于说明格式，实际应替换为目标主机地址。
- 确认主机名或IP没有写错，并确认SSH端口。默认端口通常是22，改过端口时需要使用-p指定。
- 确认私钥路径准确，尤其注意macOS、Linux和Windows路径写法不同。
- 确认服务器端保存的是对应公钥，而不是私钥内容。公钥通常以ssh-ed25519或ssh-rsa开头，并以一整行保存。
如果提示Connection timed out或Connection refused，应先处理网络、安全组或SSH服务状态；如果提示Permission denied，则重点转向用户名、密钥和认证配置。
检查私钥格式与客户端选择
区分私钥、公钥和格式
私钥只应保存在客户端，常见文件名包括id_ed25519和id_rsa；同名的.pub文件是公钥，可以上传到服务器。不要把.pub文件作为-i参数传入，也不要把私钥粘贴到authorized_keys。
较新的OpenSSH通常优先使用Ed25519密钥，密钥体积小、认证速度快；RSA兼容性更广，但应使用足够长度，通常选择3072位或4096位。若旧系统不接受Ed25519，可改用RSA；若私钥来自PuTTY的PPK文件，则需要在PuTTYgen中转换为OpenSSH可识别的格式，不能直接假设所有SSH客户端都能读取PPK。
用指纹确认是否配对
在客户端执行ssh-keygen -y -f ~/.ssh/work_ed25519，可以从私钥重新导出公钥。再使用ssh-keygen -lf得到指纹，与服务器上登记的公钥指纹比较。两者不一致时，继续调整权限没有意义，应找到正确的私钥或重新安装对应公钥。
服务器端重点检查权限
OpenSSH对密钥文件的读取较为严格。以Linux用户alice为例，相关目录通常是/home/alice/.ssh，授权文件通常是/home/alice/.ssh/authorized_keys。服务器管理员可按以下顺序检查：
- 确认目录和文件归属属于alice，而不是root或其他用户。
- 将.ssh目录权限设为700，将authorized_keys权限设为600。命令可写为chmod 700 /home/alice/.ssh和chmod 600 /home/alice/.ssh/authorized_keys。
- 检查用户家目录及上级路径是否允许该用户正常进入；目录权限过严或属主异常，都可能导致认证被拒绝。
- 确认authorized_keys中的公钥是一整行，没有被邮件换行、网页复制或编辑器截断。
执行chown alice:alice /home/alice/.ssh/authorized_keys前，应根据实际用户组确认参数。不要盲目复制命令到生产环境，尤其不要递归修改整个家目录的归属。
查看sshd配置与日志
服务器的sshd_config可能关闭了公钥认证，或限制了允许登录的用户。重点查看PubkeyAuthentication、AuthorizedKeysFile、AllowUsers、DenyUsers和PasswordAuthentication等配置。修改前先备份配置，并使用sshd -t检查语法；语法通过后再重载服务，避免直接重启造成不必要的连接中断。
日志位置随发行版不同而变化。Ubuntu和Debian通常可通过journalctl -u ssh查看服务日志，部分系统也会写入/var/log/auth.log。日志中的“Authentication refused: bad ownership or modes”通常指向目录或文件权限；“Failed publickey”则可能与用户名、私钥配对或服务端公钥内容有关。
按顺序完成一次修复
- 保留当前会话，不要在唯一的远程连接中贸然重启SSH服务。
- 在客户端用ssh -vvv -i ~/.ssh/work_ed25519 alice@主机地址观察认证过程。输出中若没有Offering public key，通常是私钥路径或客户端选择有问题。
- 在服务器确认alice的公钥已写入正确家目录，并检查属主、目录权限和换行格式。
- 用sshd -t验证配置，再查看日志中的拒绝原因。
- 修复后开启新的终端连接验证，确认成功后再关闭旧会话。
如果怀疑私钥已经泄露，应立即从服务器authorized_keys删除对应公钥，并使用新的密钥对替换。私钥口令只能降低文件被直接使用的风险，不能替代密钥轮换和账户权限管理。
常见问题
为什么密钥正确仍然提示Permission denied？
最常见原因是登录用户名不对、服务器公钥放错账户，或.ssh及authorized_keys权限、属主不符合要求。
authorized_keys能保存多把公钥吗？
可以。每把公钥单独占一行，适合同时管理电脑、跳板机和临时运维设备。
是否应该关闭密码登录？
在确认SSH密钥登录服务器稳定可用、并保留可靠应急通道后，可以按安全策略关闭密码登录。不要在密钥尚未验证前直接关闭。
Windows客户端找不到私钥怎么办？
先确认OpenSSH实际使用的路径，再用ssh -i显式指定文件。若文件来自PuTTY，应先转换为OpenSSH格式，并检查私钥是否受口令保护。
总的来说，SSH密钥登录服务器的排查顺序应是“用户名与路径、私钥格式、公钥配对、文件权限、sshd配置、日志”。按这个顺序处理，通常比反复生成密钥更快定位问题。
