这问题确实够诡异——服务器明明已经确认接受你的公钥（日志里的debug3: receive packet: type 60就是服务器认可公钥的信号），但后续却返回了type 51包（代表认证失败，要求继续尝试其他方式），而且所有SSH目标都中招，说明问题肯定出在客户端本地，和目标服务器无关。结合你的日志和操作，给你几个针对性的排查方向：

• 先确认私钥本身的有效性和权限
  虽然公钥能被服务器识别，但私钥可能存在损坏、权限异常，或者签名失效的情况：

  1. 修正私钥文件权限：运行chmod 600 ~/.ssh/id_rsa，确保只有当前用户能读写私钥，这是SSH的硬性安全要求；
  2. 验证密钥匹配性：运行ssh-keygen -y -f ~/.ssh/id_rsa，输出的公钥要和你上传到服务器/GitHub的完全一致；
  3. 尝试生成新密钥对：如果旧密钥可能损坏，生成新密钥后上传公钥再测试，排除密钥本身的问题。

• 排查签名算法兼容性问题
  从日志看，你的客户端用了rsa-sha2-512签名算法，虽然大部分服务器支持，但不排除客户端本地配置强制使用了某些服务器不兼容的算法，或者SSH版本存在bug：
  尝试在SSH命令里强制指定兼容的签名算法：

  ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -o SignatureAlgorithms=+ssh-rsa user@your-server
  

  如果这样能成功，说明是签名算法的兼容性问题，可以把这两个参数加到~/.ssh/config里全局生效。

• 排查本地SSH配置的干扰
  本地的~/.ssh/config文件可能存在全局配置，比如强制指定了错误的密钥、代理或者认证规则：

  1. 先备份当前配置：cp ~/.ssh/config ~/.ssh/config.bak；
  2. 用默认配置测试连接：ssh -F /dev/null user@your-server；
     如果默认配置能成功，说明是自定义配置里有问题，逐步排查配置项即可。

• 检查系统级安全工具的拦截
  有些杀毒软件、SELinux、AppArmor之类的安全工具会拦截SSH的签名操作，导致服务器收到的签名数据包无效，最终返回认证失败：

  1. 临时关闭SELinux测试：setenforce 0（测试完记得恢复setenforce 1）；
  2. 暂时关闭杀毒软件的实时防护，再尝试SSH连接；
     如果关闭后能成功，就需要调整安全工具的规则，允许SSH的签名操作。

另外，你已经排除了ssh-agent的问题（unset SSH_AUTH_SOCK后问题依旧），所以不用再纠结代理相关的问题，重点放在上面几个方向即可。

备注：内容来源于stack exchange，提问作者Amartya Sinha