TG咨询密钥文件看似已经上传，但登录仍提示“Permission denied (publickey)”，通常不是密钥算法本身失效，而是SSH远程登录配置中的路径、属主、权限或服务参数不一致。排查时不要反复生成密钥，先确认客户端使用了哪把私钥，再检查服务器是否读取了对应公钥。
先判断失败发生在哪一层
在Windows 11、macOS或其他类Unix客户端上，首次排查可以使用详细日志。命令为：ssh -vvv 用户名@服务器地址。输出中如果出现“Offering public key”，说明客户端已经找到并尝试使用私钥；如果服务器随后拒绝，重点检查账号、authorized_keys和sshd配置。如果连“Offering public key”都没有，可能是私钥路径不对、权限限制或SSH客户端没有加载该密钥。
若提示“Connection refused”，问题更接近服务没有监听目标端口；若提示“Connection timed out”，还需检查网络路径、防火墙或安全组。不要把这几类错误都归结为SSH远程登录配置中的密钥问题。
检查公钥文件、属主和权限
以Rocky Linux服务器为例，登录控制台或使用其他可用入口后，切换到目标账号，检查家目录和密钥文件：
- 确认账号的家目录：getent passwd 用户名，查看最后一个字段是否为预期路径。
- 确认目录存在：ls -ld /home/用户名 /home/用户名/.ssh。
- 确认公钥文件内容：ls -l /home/用户名/.ssh/authorized_keys，并用cat查看是否包含客户端公钥的一整行。
- 修正属主：chown -R 用户名:用户组 /home/用户名/.ssh。
- 修正权限：chmod 700 /home/用户名/.ssh，再执行chmod 600 /home/用户名/.ssh/authorized_keys。
目录通常不应允许同组或其他用户写入，authorized_keys也不应设置为全局可写。部分系统启用了StrictModes，发现家目录或密钥路径存在不安全权限后，sshd可能直接拒绝使用该文件。家目录本身也应保持合理权限，例如常见的755或更严格设置，但应结合服务器的账号管理要求调整。
确认公钥没有被破坏
authorized_keys中的一把公钥通常占一行，不能因为复制过程产生换行，也不能把私钥内容放到服务器上。使用ssh-keygen -y -f 私钥路径可以从私钥导出公钥，再与服务器文件中的对应行进行比对。若服务器使用了自定义文件位置，还要检查sshd_config中的AuthorizedKeysFile设置，不能只盯着默认路径。
核对服务状态与实际配置
权限无误后，检查sshd是否运行以及配置文件能否通过语法验证。Rocky Linux常用命令如下：
- 执行sudo sshd -t。没有输出通常表示语法检查通过；若有错误，先修正报错行。
- 执行sudo systemctl status sshd，查看服务是否处于active状态及最近的失败原因。
- 需要重载配置时使用sudo systemctl reload sshd；只有服务未运行或重载失败时，才考虑sudo systemctl restart sshd。
- 确认监听端口：sudo ss -lntp | grep sshd，核对监听地址和端口是否与客户端命令一致。
修改sshd_config前应保留当前会话，并在重启前执行sshd -t，避免因拼写错误关闭唯一管理通道。关注PubkeyAuthentication是否被禁用、AuthorizedKeysFile是否指向正确位置，以及Match User或Match Group规则是否覆盖了目标账号。若同时设置了AllowUsers、AllowGroups等访问控制项，也要确认账号确实被允许。
日志能缩小定位范围
服务状态只显示结果，日志更适合判断拒绝原因。可执行sudo journalctl -u sshd -b查看本次启动后的记录，也可以使用sudo journalctl -u sshd -f，然后在另一终端重新登录。日志中若出现“Authentication refused: bad ownership or modes”，优先回到文件属主和权限；若提示用户不存在或不在允许列表，应检查账号及访问控制；若显示SELinux拒绝，在确认路径和属主正确后，可用restorecon -Rv /home/用户名/.ssh恢复默认安全上下文。
| 现象 | 优先检查项 | 处理方向 |
|---|---|---|
| Permission denied (publickey) | 公钥内容、文件权限、账号规则 | 校验authorized_keys并检查sshd配置 |
| Connection refused | sshd服务与监听端口 | 执行sshd -t、systemctl status和ss检查 |
| 配置修改后服务起不来 | 配置语法或重复指令 | 保留现有会话，先用sshd -t修复 |
| 权限正确但仍被拒绝 | SELinux上下文、Match规则 | 查看journalctl并核对实际生效配置 |
更稳妥的SSH远程登录配置习惯
完成修复后，建议从一台新的客户端连接验证，不要立刻关闭原有会话。客户端可显式指定私钥，例如ssh -i 私钥路径 用户名@服务器地址，避免多个密钥同时尝试造成误判。确认密钥登录稳定后，再按管理要求决定是否关闭密码登录；修改前必须确保至少保留一个可用的密钥或应急入口。
总的来说，SSH远程登录配置排查应遵循“客户端日志—账号路径—权限属主—公钥匹配—服务状态—系统日志”的顺序。这样既能快速区分密钥问题与服务问题，也能降低修改sshd配置时误锁管理员的风险。
常见问题
1. authorized_keys权限必须固定为600吗？
600是常见且稳妥的设置。某些系统允许更宽松的可读权限，但不应让其他用户拥有写权限，最终仍应以系统的StrictModes检查结果和安全要求为准。
2. 修改sshd_config后是否必须重启？
不一定。语法检查通过后通常可使用systemctl reload sshd让新配置生效，重启适用于服务异常或需要重新初始化的情况。
3. 为什么密钥内容正确仍然登录失败？
还可能是登录用户名错误、sshd读取了其他文件、Match规则覆盖账号、SELinux上下文异常，或客户端实际使用了另一把私钥。
4. 可以直接删除旧密钥再重新上传吗？
不建议直接删除。应先追加并验证新公钥能够登录，再移除不再使用的旧授权，避免失去唯一的远程入口。
