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

我想通过SSH克隆远程Gitlab服务器的存储库。 我正在使用Gitlab CE version 9.3.9 755bb71TortoiseGIT version 2.5.0git (for windows) version 2.14.0

SSH密钥正确安装,因为我已经testing了使用身份validation

 ssh -vT git@192.168.100.100 -i /path/to/.ssh/key 

使用上面的密钥,我得到以下消息authentication成功

 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: curve25519-sha256@libssh.org debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com 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 no-more-sessions@openssh.com 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 eow@openssh.com 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. 

但是当我尝试使用不同的SSH密钥从另一台Linux机器上git clone ,它是成功的,我在gitlab服务器上的gitlab gitlab-shell.log获得了以下信息

 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个小时试图debugging一切,我不知道有什么区别或究竟是什么问题。 我也尝试添加以下在我的本地.gitconfig文件为TortoiseGit但不会改变任何东西。

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

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

Solutions Collecting From Web of "无法在Windows上克隆,但可以从Gitlab服务器上的Linux克隆"

注:我只是升级到Git 2.14.0的Windows …没有任何的SSH网址工作:

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

origin是一个ssh url)

另一个副作用: git-for-windows / git issue 1258

 fatal: protocol error: bad line length character: Not 

看起来好像BitBucket查看argv[0] (通常是git-upload-pack ,回归git)来确定它是否是允许的命令。

所以我认为git被拒绝,而git-upload-pack不是。

GitLab: gitlab-ce issue 360​​28上出现同样的错误。
当检测到git xxx命令时, 挂起的合并请求 显式恢复git-xxx

请参阅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 

在Git for Windows方面,正在进行修复: 请参阅commit 0f33428

还原“git_connect:宁愿Git的内置虚线形式”

看起来,这种改变(当git-upload-pack不在PATH时,修改了与本地仓库交互的测试),SSH访问就会降低。

一个Git for Windows 2.14.0(2)正在工作,刚刚发布(2017-08-07T11:05:34Z UTC)30分钟前在这个编辑的时间。


原始答案

如果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文件 。

Bitbucket server和Gogs都看到类似的问题。

看来,在git 2.14.0(可能只在Windows上)有所改变,需要更新产品或修复git。