在我们的例子中，这不是用户/客户端的问题，而是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访问就可以了。

在我们的例子中，这不是用户/客户端的问题，而是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访问就可以了。

转到终端，重新生成ssh密钥。ssh - keygen类型。它会问你想保存在哪里，输入路径。

然后将公钥复制到gitlabs平台。它通常从ssh-rsa开始。

我也有同样的问题，我通过添加一个新的ssh密钥来解决它:

ssh-keygen -t ed25519 -C "email@example.com" 将您的公共SSH密钥复制到剪贴板(xclip -sel clip < ~/. SSH /id_ed25519. exe)。pub在我的情况下在Linux上) 在gitlab上，转到settings=>ssh keys，然后跳过新密钥

另一个可能导致这种行为的问题是当你有2个可能的%HOME%-locations的设置时。

我使用的是个人电脑，其中一些文档存储在本地，另一些存储在网络驱动器上。一些应用程序认为C:\Users\<MyUserName>\是my %home%，另一些应用程序认为U:\是home。

原来ssh-keygen把我的私钥放在C:\users\<MyUserName>\下，ssh -T和ssh -v也在那里查找。

所以一切似乎都很好，除了git克隆，git推和其他人在U:\寻找一个键。 它失败了，所以我得到了前面提到的错误。

我花了一个小时才找到答案，但最终解决方案很简单:我复制了C:\Users\<MyUserName>\中的所有内容。ssh到U:\.ssh

我遇到这个问题是因为Windows-10上的ssh-agent冲突。 如果你也在使用Windows-10，那么请仔细阅读我的详细解决方案

如果你不在windows-10，那么请检查是否:

您的ssh代理正在运行 将正确的私钥添加到ssh-agent中 正确的公钥被添加到你的github帐户(你可以克隆，所以这一步应该是好的)