Fatal编程技术网
  • linux/
  • Can'；不能在windows上克隆，但可以从Gitlab服务器在linux上克隆

Can'；不能在windows上克隆，但可以从Gitlab服务器在linux上克隆

linux windows git gitlab

Can'；不能在windows上克隆，但可以从Gitlab服务器在linux上克隆,linux,windows,git,gitlab,tortoisegit,Linux,Windows,Git,Gitlab,Tortoisegit,我正在尝试通过SSH从远程Gitlab服务器克隆存储库。我使用的是Gitlab CE版本9.3.9 755bb71和Ortoisegit版本2.5.0和git（适用于windows）版本2.14.0 SSH密钥安装正确，因为我已经使用 ssh -vT git@192.168.100.100 -i /path/to/.ssh/key 我使用上面的密钥获得以下认证成功消息 OpenSSH_7.5p1, OpenSSL 1.0.2k 26 Jan 2017 debug1: Reading conf

我正在尝试通过SSH从远程Gitlab服务器克隆存储库。我使用的是
Gitlab CE版本9.3.9 755bb71
和
Ortoisegit版本2.5.0
和
git（适用于windows）版本2.14.0

SSH密钥安装正确，因为我已经使用

ssh -vT git@192.168.100.100 -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: 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
在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.
我花了10多个小时试着调试所有的东西，我不知道有什么不同，或者问题到底出在哪里。我还尝试在我的本地
.gitconfig
文件中为TortoiseGit添加以下内容，但这并没有改变任何事情

[remote "origin"]
  uploadpack = git-upload-pack
最后，通过HTTPS克隆同一存储库工作正常，使用用户名/密码没有任何问题。

注意：我只是升级到Git 2.14.0 for Windows。。。并且所有ssh url都不起作用：

> git ls-remote
GitLab: Disallowed command
fatal: Could not read from remote repository.
（使用
origin
作为ssh url）

另一个副作用：

看起来BitBucket似乎在查看
argv[0]
（通常是
git upload pack
，带有回归git）以确定它是否是允许的命令

因此，我认为是出于设计原因，
git
被拒绝，而
git upload pack
则没有

GitLab上的同类错误：。
当检测到
git xxx
命令时，显式还原
git xxx

看

在Git for Windows端，正在进行修复：

还原“git_connect：更喜欢git的内置格式而不是虚线格式” 这一变化似乎是为了修复测试 当
git upload pack
不在 
PATH
）在SSH访问时返回

一个正在制作中，在本次编辑时30分钟前刚刚发布（2017-08-07T11:05:34Z UTC）

原始答案

如果
key1
与您的
/path/to/.ssh/key
相同，并且确实标识了John Doe，则意味着John Doe无权访问该repo（）。
检查key2是否与其他用户关联

如果两个键都引用同一个用户，则更多的是本地配置问题（如中所示）。 还要检查您的龟龟是否使用与测试中相同的钥匙：

set "GIT_COMMAND_SSH=ssh -v"
# launch TortoiseGit from that CMD session
然后，您将看到Ortoisegit在使用ssh url克隆repo时使用了什么。您可能需要这样做。

两者都出现了类似的问题

git 2.14.0中似乎发生了一些变化（可能仅在Windows上）这需要对产品进行更新或对git进行修复。

为什么不通过https进行克隆并将源站设置为指向远程gitlab服务器？您的意思是将源站设置为将远程gitlab服务器指向SSH而不是https？请确认您已将SSH密钥添加到SSH代理，并且已将代理pid添加到SSH密钥？请忽略原点。它是否适用于Git 2.13？顺便说一句，正如这里所述，Git for windows 2.13.0是一种解决方案，Git for windows 2.14.0.windows2也是如此。我没有尝试更改gitlab-shell.rb，因为我没有进行后续操作所需的时间。到目前为止，我一直在为windows更改git版本。@而且一切都很好。因此，Git for Windows 2.14.0（2）中修复的回归就是导致此问题的原因。。。这是一个相当大的缺陷回归。确实是一个相当大的回归。我希望这篇文章能为其他人节省好几个小时。正如你所知，这个解决方案只起了一半的作用。在获取或克隆时，上传包的问题解决了，但在推到远程respository时，接收包的问题仍然存在。@这就奇怪了。您是否有其他错误消息？ 
> git ls-remote
GitLab: Disallowed command
fatal: Could not read from remote repository.

fatal: protocol error: bad line length character: Not

  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

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