无法使用 ssh 克隆现有存储库，并且 ssh 配置似乎没问题

Question

这是我的情况：我有两个私人存储库。

• git@github.com:syra37fGIT/Angular.git
• git@github.com:syra37fGIT/temp.git

目前，我通过克隆仅为其中一个添加了一个遥控器。

$ git remote -v
origin  git@github.com:syra37fGIT/temp.git (fetch)
origin  git@github.com:syra37fGIT/temp.git (push)

我认为 ssh 配置正确，因为：

我生成了私钥（id_rsa）和公钥（id_rsa.pub）

$ ls -al ~/.ssh
total 28
drwxr-xr-x 1 Pietro 197121    0 Mar  5 00:18 ./
drwxr-xr-x 1 Pietro 197121    0 Mar 17 09:19 ../
-rw-r--r-- 1 Pietro 197121 3389 Mar  5 00:18 id_rsa
-rw-r--r-- 1 Pietro 197121  747 Mar  5 00:18 id_rsa.pub
-rw-r--r-- 1 Pietro 197121 2790 Mar  5 00:29 known_hosts

公钥已正确设置到我的 github 帐户个人设置/SSH 和 GPG 密钥中

帐户上设置的公钥

私钥似乎也已正确注册

$ eval `ssh-agent -s`
Agent pid 7696

$ ssh-add
Identity added: /c/Users/Pietro/.ssh/id_rsa (syra37fGIT@yandex.com)

作为证明，我实际上可以将提交推送到添加的存储库中而不会出现问题（因为 ssh 处于活动状态，所以不需要密码）

(master)$ echo -e "\ndamn u damn" > README.txt
(master)$ git add .
(master)$ $ git commit -m "damn u commit"
          [master dae7dfd] damn u commit
            1 file changed, 2 insertions(+), 4 deletions(-)
(master)$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 263 bytes | 263.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To github.com:syra37fGIT/temp.git 
  54bc492..dae7dfd  master -> master

认证测试也有效

$ ssh -T git@github.com
Hi syra37fGIT! You've successfully authenticated, but GitHub does not provide shell access.

鉴于此，当我尝试克隆其他存储库时，会出现以下错误消息......

$ git clone git@github.com:syra37fGIT/Angular.git
Cloning into 'Angular'...
\302\226git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

https://help.github.com/en/articles/error-permission-denied-publickey中建议的每个提示都 得到满足（我在 Windows 机器上）。我哪里做错了？

提示：有可能两个存储库之一首先使用 https 克隆，然后转换为 ssh（从 HTTPS 到 SSH））...我不知道这是否可以作为问题的线索。

更新：正如下面的评论所暗示的，问题是虽然从视觉上看存储库字符串是正确的，但实际发送的字符串是错误的。问题解决了。

Answer 1

从这里可以看出，如果命令是复制粘贴的结果，它可以使用不可见的特殊字符，这将使命令失败。

\n\n

在这种情况下，需要进行的基本双重检查是再次手动键入命令，并查看问题是否仍然存在。

\n\n

正如此处所评论的，\' \\302\\226\'0xC2 0x96又名U+0096UTF-8 编码。
\n在这里查看更多：

\n\n

\n

其原始来源可能是某些单字节 8 位编码中的字节 0x96，该编码在途中的某个地方被错误地转码。可能这最初是Windows CP1252破折号“ \xe2\x80\x93”，在该编码中具有字节值 96，已被转换为 UTF-8，就好像它是latin-1 (ISO/IEC 8859-1)一样，这并不罕见。

\n

\n