Gitee ssh 公钥配置好后,仍然 permission denied 的排查过程及解决方法

突如其来
今天 git pull 一个老项目,之前一直提交的好好的,这次突然报错 git@gitee.com: Permission denied (publickey).,明明是我自己的 repo,居然告诉我没有权限??

在这里插入图片描述
无脑尝试
一开始以为是本地 id_rsa.pub 变更导致 gitee 上原有的记录失效,于是 ssh-keygen 命令重新生成了下,贴到 gitee 上,还是老样子。

 

然后我怀疑我在折腾的时候改乱了 git 的配置,又重新 pacman -S git 强制 reinstall 了下,还是老样子。

我又尝试用 ssh 方式去 clone gitee 上的其他 repo 也是 permission denied,用 http 方式就没问题。但是难道是 ~/.ssh 目录下的文件的锅?于是我转移阵地,到 github 上试了下,github 上可以正常 clone,畅通无阻。

奇了怪了,难道是 gitee 的 bug?于是,我开了两个 terminal,左边是一台 ubuntu 的开发机,右边是我本地。双双重新生成 ssh-key,重新贴到 gitee 上,重新 clone,一气呵成。

然而,开发机上畅通无阻,本地无权限依旧…

蛛丝马迹
后来看到,有人遇到过 ssh公钥配置好后还是不能访问到码云网 问题,虽然作者没有解决,但下面的回答提供了一种思路:ssh -Tvvv git@gitee.com 可以打印详细的 log!

我在远程和本地分别执行 ssh -Tvvv git@gitee.com,虽然和之前一样,一边是 successfully authenticated,一边是 Permission Denied,但不同的是,这次有了更详细的日志了!

不怕 error,就怕原因不明的 error。这下好办了,两边日志一行一行对比,简直看花了眼,终于在右侧找到一些端倪:debug1: send_pubkey_test: no mutual signature algorithm

嗯?为啥?没有这个签名算法??

在这里插入图片描述
拨云见日
既然已经发现 send_pubkey_test: no mutual signature algorithm,当然是问 google 啦。根据 SSH-RSA key rejected with message “no mutual signature algorithm” 中说的:

 

意思是说,RSA SHA-1 算法已经过时了。如果你一定要用的话,可以在 ssh config 里面将其开启:

# 编辑 ssh 配置文件
sudo vim /etc/ssh/ssh_config
# 添加以下内容
PubkeyAcceptedKeyTypes +ssh-rsa


柳暗花明
我估计是某次系统更新的时候把原有的 RSA SHA-1 算法 deprecated 掉了。

按着上面说的,修改 ssh config 后保存,重新 git clone 一下,就可以正常使用了。

在这里插入图片描述

 

————————————————
版权声明:本文为CSDN博主「寒泉Hq」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/sinat_42483341/article/details/121108774

  • 6
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
配置 SSH 免密登录时遇到 "Permission denied, please try again." 错误,可能有以下几个原因和解决方法: 1. 错误的用户名或密码:请确保在 SSH 配置中正确输入了目标主机的用户名和密码。如果不确定,可以尝试手动使用该用户名和密码登录目标主机,确认是否有效。 2. SSH 服务未启动:检查目标主机上的 SSH 服务是否已经启动。可以通过运行以下命令来检查 SSH 服务状态: ``` sudo service ssh status ``` 如果 SSH 服务未启动,可以使用以下命令启动: ``` sudo service ssh start ``` 3. 错误的密文件或路径:确保本地机器上的密文件路径正确,并且目标主机上的 `~/.ssh/authorized_keys` 文件包含了正确的。可以尝试重新生成密对,并将添加到目标主机的 `~/.ssh/authorized_keys` 文件中。 4. 权限问题:检查目标主机上的相关文件和目录的权限是否正确。一般来说,`.ssh` 目录权限应为 700,`authorized_keys` 文件权限应为 600。 5. 防火墙或安全组设置:如果目标主机启用了防火墙或安全组,确保 SSH 端口(默认为 22)是开放的。可以尝试临时关闭防火墙或安全组规则,然后再次尝试免密登录。如果可以成功登录,则需要相应地配置防火墙或安全组规则。 如果上述方法都无法解决问题,建议查看目标主机的 SSH 日志文件(通常位于 `/var/log/auth.log` 或 `/var/log/secure`),以获取更详细的错误信息。根据具体的错误信息,可以进一步排查解决问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值