GitLab突发Permission denied (publickey)错误 此前连接正常 密钥配置无误

从你提供的SSH调试日志可以提取3个关键信息：

• 本地Git Bash自带的OpenSSH客户端可以正常读取/c/Users/xxx/.ssh/id_ed25519私钥，并且已经主动把对应公钥的指纹SHA256:uEcoFZk1Nh6/5KRdoKFtktiOtX8qoUupC4ohwKrvvWA发送给了GitLab服务器
• 服务器收到该公钥后未完成身份校验，直接返回了需要继续publickey认证的响应，最终触发权限拒绝
• 服务端运行的是OpenSSH 7.2p2 Ubuntu-4ubuntu2.10版本，属于较老的SSH实现，存在已知的算法兼容问题

按优先级从高到低排查即可：

• 核对公私钥匹配关系
  本地执行ssh-keygen -lf ~/.ssh/id_ed25519.pub命令，拿到公钥的生成指纹，和GitLab个人SSH密钥列表里的对应密钥指纹做比对。如果两个指纹不一致，说明你本地的id_ed25519私钥已经被替换、或者对应的公钥根本没有和当前GitLab账号绑定。
• 验证老版本OpenSSH的ed25519兼容问题
  你本地使用的OpenSSH 8.4p1和服务端OpenSSH 7.2p2之间存在ed25519算法的兼容bug：新客户端发起ed25519认证签名时，老版本服务端会出现识别失败的情况。这类问题往往是GitLab服务器近期自动更新了系统补丁、调整了SSH服务端的配置参数，才会出现之前正常、现在突然连不上的表现。
  可以直接执行带兼容参数的测试命令验证：
  ssh -Tv -o PubkeyAcceptedKeyTypes=+ssh-ed25519 git@xxx
  如果这条命令可以正常连接，就需要在本地的~/.ssh/config文件里为目标GitLab域名添加固定配置：

  Host 你的GitLab域名
    PubkeyAcceptedKeyTypes=+ssh-ed25519
  

• 检查GitLab端的密钥生效状态
  部分自建GitLab版本会存在密钥校验逻辑的策略调整：比如密钥设置了自动过期时间、账号SSH访问权限被临时限制、密钥关联的账号被触发安全验证规则，就算密钥之前有正常使用记录，也会在策略变更后直接拒绝认证。
  这种情况可以直接在GitLab端删除原有SSH密钥条目，重新上传本地~/.ssh/id_ed25519.pub的完整内容，等待1分钟后再测试连接。
• 检查本地文件权限配置
  虽然Windows平台的Git Bash对私钥的权限检查比Linux环境宽松，但仍需确认：.ssh目录和目录下的私钥文件，仅对当前Windows登录账号开放读取权限，其他系统用户、用户组的权限全部移除。如果权限配置过宽，部分版本的SSH客户端会拒绝加载私钥（从当前日志来看你已经成功加载了ed25519私钥，该项可最后排查）

内容的提问来源于stack exchange，提问作者SGiux