我的问题是我使用了一个具有sudo访问权限的非root用户。但即使是sudo git克隆…没有工作。解决方案是为项目创建文件夹，chown用户项目文件夹，然后运行克隆没有sudo。

在我们的例子中，这不是用户/客户端的问题，而是Gitlab服务器端的问题。

我们在CentOS 7.1上运行本地Gitlab CE 12.9实例。

我们发现在服务器上，.ssh/authorized_keys文件没有正确更新。用户创建他们的SSH密钥(遵循Gitlab指南)并将其添加到Gitlab服务器，但服务器不更新authorized_keys，因此总是会导致权限拒绝错误。

一个解决方法是通过运行以下命令重建authorized_keys文件:

$ sudo gitlab-rake gitlab:shell:setup

这适用于任何在运行rake任务之前添加密钥的人。对于下一个要添加密钥的用户，必须有人再次手动运行rake任务。

一个更持久的解决方案是不使用authorized_keys文件，而是在Gitlab数据库上使用索引查找:

GitLab Shell provides a way to authorize SSH users via a fast, indexed lookup to the GitLab database. GitLab Shell uses the fingerprint of the SSH key to check whether the user is authorized to access GitLab. Add the following to your sshd_config file. This is usually located at /etc/ssh/sshd_config, but it will be /assets/sshd_config if you're using Omnibus Docker: Match User git # Apply the AuthorizedKeysCommands to the git user only AuthorizedKeysCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-keys-check git %u %k AuthorizedKeysCommandUser git Match all # End match, settings apply to all users again Reload OpenSSH: # Debian or Ubuntu installations sudo service ssh reload # CentOS installations sudo service sshd reload Confirm that SSH is working by removing your user's SSH key in the UI, adding a new one, and attempting to pull a repo.

默认情况下(我们安装时的默认情况)，在Admin Area > Performance Optimization设置中检查了Write to authorized_keys文件。因此，我们未选中该选项，转而使用Gitlab数据库。

在设置了索引查找并取消对Write to authorized_keys文件的检查之后，SSH访问就可以了。

步骤1: 在~/中添加了一个配置文件。Ssh /config文件，看起来像

   User git
   Hostname gitlab.com
   IdentityFile ~/.ssh/id_rsa_gitlab
   TCPKeepAlive yes
   IdentitiesOnly yes

步骤2:克隆没有sudo的git repo。 文档:https://gitlab.com/help/ssh/README working-with-non-default-ssh-key-pair-paths

**有时在~/中有配置。ssh/config，但是，IdentityFile路径错误。您可以像这样检查文件名ls ~/.ssh/。gitlab的文件通常是id_ed25519。因此正确的配置是IdentityFile ~/.ssh/id_ed25519

我有gitlab运行docker，这是我所做的解决我的问题。

发现在docker /var/log/gitlab/sshd/current内部出现了多条消息:

身份验证被拒绝:文件/var/opt/gitlab/.ssh/authorized_keys的所有权或模式错误

之后，我将该文件的所有权从99:users更改为git:users:

Chown git:users authorized_keys

我认为简单的解决方案是将私钥添加到身份验证代理(如果您的密钥不是~/.ssh/id_rsa)，

ssh-add ~/.ssh/<your private key>

基本上让ssh-agent来处理它。

此外，您可以永久地添加它。

我知道，我回答这个问题很晚，甚至StackOverflow确认我是否真的想回答。我回答是因为没有人真正描述了实际的问题，所以想分享。

最基本的

首先，了解这里的遥控器是什么。Remote是GitLab，而你的系统是本地的，所以当我们讨论远程源时，在你的git Remote -v输出中设置的URL就是你的远程URL。

的协议

基本上，Git的克隆/推/拉主要适用于两种不同的协议(也有其他协议)

HTTP协议 SSH协议

当你克隆一个repo(或更改远程URL)并使用HTTPs URL如https://gitlab.com/wizpanda/backend-app.git时，它使用第一种协议，即HTTP协议。

而如果你克隆了这个repo(或者改变了远程URL)，并使用git@gitlab.com:wizpanda/backend-app.git这样的URL，那么它就会使用SSH协议。

HTTP协议

在这个协议中，每个远程操作，即克隆、推和拉，都使用简单的身份验证，即远程(在本例中为GitLab)的用户名和密码，这意味着对于每个操作，您必须输入您的用户名和密码，这可能很麻烦。

所以当你推/拉/克隆时，GitLab/GitHub用你的用户名和密码验证你，它允许你做操作。

如果你想尝试这样做，你可以通过运行命令git remote set-url origin < HTTP -git- URL >来切换到HTTP URL。

为了避免这种情况，可以使用SSH协议。

SSH协议

简单的SSH连接使用公私密钥对。因此，在您的情况下，GitLab无法对您进行身份验证，因为您使用SSH URL进行通信。现在，GitLab一定以某种方式了解你。为此，您必须创建一个公共-私有密钥对，并将公钥提供给GitLab。

现在当你用GitLab推/拉/克隆时，GIT(内部是SSH)将默认提供你的私钥给GitLab并确认你的身份，然后GitLab将允许你执行操作。

所以我不会重复默罕默德已经给出的步骤，我只是从理论上重复。

生成密钥对' SSH -keygen -t rsa -b 2048 -C "My Common SSH key " 默认情况下，生成的密钥对在~/中。SSH名为id_rsa。Pub(公钥)& id_rsa(私钥)。 您将把公钥存储到您的GitLab帐户(相同的密钥可以用于多个或任何服务器/帐户)。 当你克隆/推/拉时，GIT会提供你的私钥。 GitLab将私钥与公钥匹配，并允许您执行。

Tips

您应该始终创建一个至少2048字节的强rsa密钥。执行命令为ssh-keygen -t rsa -b 2048。

https://gitlab.com/help/ssh/README#generating-a-new-ssh-key-pair

一般认为

这两种方法都有各自的优点和缺点。在我输入上面的文本后，我去搜索了更多关于这个的信息，因为我从来没有读过关于这个的东西。

我找到了这个官方文档https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols，它讲述了更多关于这方面的内容。我在这里的观点是，通过阅读错误并对错误进行思考，你可以建立自己的理论或理解，然后可以匹配一些谷歌结果来解决问题:)