无法在 Windows 上克隆，但可以从 Gitlab 服务器在 Linux 上克隆

我正在尝试通过 SSH 从远程 Gitlab 服务器克隆存储库。我在用Gitlab CE version 9.3.9 755bb71 and TortoiseGIT version 2.5.0 and git (for windows) version 2.14.0

SSH 密钥已正确安装，因为我已使用以下命令测试了身份验证

ssh -vT [email protected] -i /path/to/.ssh/key

我收到以下消息，表明使用上述密钥身份验证成功

OpenSSH_7.5p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.100.100 [192.168.100.100] port 22.
debug1: Connection established.
debug1: identity file /path/to/.ssh/key type 1
debug1: key_load_public: No such file or directory
debug1: identity file /path/to/.ssh/key-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to 192.168.100.100:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:fEztD+bNxKRs24poXJMlP0GBAP6Q1dZT80OhQAtDQJE
debug1: Host '192.168.100.100' is known and matches the ECDSA host key.
debug1: Found key in /path/to/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /path/to/.ssh/key
debug1: Server accepts key: pkalg ssh-rsa blen 535
Enter passphrase for key '/path/to/.ssh/key':
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.100.100 ([192.168.100.100]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
Welcome to GitLab, John Doe!
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 3476, received 3264 bytes, in 2.2 seconds
Bytes per second: sent 1574.0, received 1478.0
debug1: Exit status 0

当我在 Windows 上使用 TortoiseGit 克隆存储库时，我在客户端上收到以下错误

Cloning into 'C:\path\folder'...
GitLab: Disallowed command
fatal: Could not read from remote repository.

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

在gitlab服务器上，在gitlab-shell.log我收到以下警告消息

WARN -- : gitlab-shell: Attempt to execute disallowed command <git upload-pack '/path/to/repo.git'> by user with key key-1.

但当我尝试时git clone从另一台具有不同 SSH 密钥的 Linux 机器成功，我收到以下信息消息gitlab-shell.log在gitlab服务器上

INFO -- : gitlab-shell: executing git command <gitaly-upload-pack  {"repository":{"path":"/very/long/path/to/repo.git"},"gl_id":"key-2"}> for user with key key-2.

我花了 10 多个小时尝试调试所有内容，但我不确定有什么区别或问题到底出在哪里。我还尝试在本地添加以下内容.gitconfig文件 TortoiseGit 但这并没有改变任何东西。

[remote "origin"]
  uploadpack = git-upload-pack

最后，通过 HTTPS 克隆相同的存储库工作正常，使用用户名/密码没有任何问题。

注意：我刚刚升级到 Windows 版 Git 2.14.0...并且所有 ssh url 都不起作用：

> git ls-remote
GitLab: Disallowed command
fatal: Could not read from remote repository.

(with origin是 ssh url）

另一个副作用：git-for-windows/git 问题 1258

fatal: protocol error: bad line length character: Not

看起来好像 BitBucket 在看argv[0]（通常git-upload-pack，使用回归 git) 来确定它是否是允许的命令。

所以我认为这是设计使然git被拒绝，同时git-upload-pack is not.

GitLab 上出现同样的错误：gitlab-ce 问题 36028.
The 待处理的合并请求 显式恢复git-xxx当它检测到一个git xxx command.

See gitlab_shell.rb#parse_cmd(args)

  def parse_cmd(args)
    # Handle Git for Windows 2.14 using "git upload-pack" instead of git-upload-pack
    if args.length == 3 && args.first == 'git'
      @command = "git-#{args[1]}"
      args = [@command, args.last]
    else
      @command = args.first
    end

在 Windows 端的 Git，修复正在进行中：请参阅提交 0f33428

恢复“git_connect：更喜欢 Git 的内置功能而不是虚线形式”

看来这个更改（旨在修复测试 与本地存储库交互时git-upload-pack不在PATH) SSH 访问回归。

A 适用于 Windows 的 Git 2.14.0(2)正在开发中，并且在本次编辑时 30 分钟前刚刚发布 (2017-08-07T11:05:34Z UTC)。

原答案

If key1和你的一样/path/to/.ssh/key并且确实识别了 John Doe，这应该意味着 John Doe 无权访问该存储库（就像这里一样).
检查 key2 是否与不同的用户关联。

如果两个键都引用同一用户，那么这更多是本地配置问题（如这个答案）。 还要检查您的 TortoiseGit 是否使用与测试中相同的密钥：

set "GIT_COMMAND_SSH=ssh -v"
# launch TortoiseGit from that CMD session

然后，您将看到 TortoiseGit 在使用 ssh url 克隆存储库时使用的内容。你可能需要定义一个.ssh/config file.