2

I am trying to clone a repository from a remote Gitlab server over SSH. I am using Gitlab CE version 9.3.9 755bb71 and TortoiseGIT version 2.5.0 and git (for windows) version 2.14.0

SSH Keys are installed correctly as I have tested the authentication using 

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

I get the following message for authentication success using the above 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

When I use TortoiseGit on windows to clone a repository I get the following error on the client

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.

On the gitlab server, in the gitlab-shell.log I get the following warning message

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

But when I try git clone from another linux machine with a different SSH key it's successfull and I get the following info message in gitlab-shell.logon the gitlab server

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.

I have spent more than 10 hours trying to debug everything and I am not sure what's the difference or where exactly is the problem. I have also tried adding the following in my local .gitconfig file for TortoiseGit but that doesn't change anything.

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

Finally, cloning the same repository over HTTPS works fine, without any problem using a username / password.

andthereitgoes
  • 819
  • 2
  • 10
  • 24
  • why not just clone over https and set the origin to point to the remote gitlab server? – BenKoshy Aug 07 '17 at 02:34
  • you mean set the origin to point the remote gitlab server to SSH instead of HTTPS? – andthereitgoes Aug 07 '17 at 02:49
  • pls confirm you've added the ssh key to the ssh agent and also that you've added the agent pid to the ssh key? – BenKoshy Aug 07 '17 at 03:21
  • pls ignore the origin point. – BenKoshy Aug 07 '17 at 03:22
  • Does it work with Git 2.13? – MrTux Aug 07 '17 at 08:00
  • I have [updated my answer](https://stackoverflow.com/a/45539717/6309) with the GitLab fix to apply. – VonC Aug 07 '17 at 08:40
  • Thanks @VonC for your excellent findings. No need for the link to read abot about accept / vote. I haven't tried either of your solutions or taken a look at bug links yet, as I have been at work. Will do so pronto and update accordingly. – andthereitgoes Aug 07 '17 at 12:41
  • Indeed - the key word is 'good' answers and I did upvote the answer/s that I found satisfactory at the time to my requirement. On your insistence, I will take another look at my other questions too. Thanks. – andthereitgoes Aug 07 '17 at 12:47

2 Answers2

6

Note: I just upgrade to Git 2.14.0 for Windows... and none of the ssh url are working:

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

(with origin being an ssh url)

Another side effect: git-for-windows/git issue 1258

fatal: protocol error: bad line length character: Not

It looks as if BitBucket looks at argv[0] (typically git-upload-pack, with the regression git) to determine whether it is a permitted command.

So I think it is by design that git is rejected while git-upload-pack is not.

Same kind on error on GitLab: gitlab-ce issue 36028.
The pending merge request explicitly restore git-xxx when it detects a 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

At the Git for Windows side, a fix is in progress: see commit 0f33428

Revert "git_connect: prefer Git's builtins over dashed form"

It would appear that this change (which was intended to fix tests interacting with local repositories when git-upload-pack was not in the PATH) regresses on SSH access.

A Git for Windows 2.14.0(2) is in the work and was just released (2017-08-07T11:05:34Z UTC) 30 minutes ago at the time of this edit.

Original answer

If key1 is the same as your /path/to/.ssh/key and does identify John Doe, that should mean John Doe does not have access to that repo (as in here).
Check that key2 is associated with a different user.

If both keys reference the same user, then it is more a local configuration issue (as in this answer). Check also that your TortoiseGit does use the same key as in your test: 

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

You will then see what TortoiseGit is using when cloning the repo with an ssh url. You might need to define an .ssh/config file.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Incidentally, as described here git for windows 2.13.0 worked as a solution and so did git for windows version 2.14.0.windows2. I didn't attempt changing the gitlab-shell.rb as I didn't have the time required for the follow up actions. So far changing the git versions for windows, wokred for me. – andthereitgoes Aug 07 '17 at 12:43
  • @andthereitgoes Excellent. So the regression fixed in Git for Windows 2.14.0(2) is the one causing this issue... That was quite a bug regression. – VonC Aug 07 '17 at 12:45
  • Indeed quite a regression. I am hoping this post saves others good few hours. – andthereitgoes Aug 07 '17 at 12:57
  • just so you know this solution only half worked.The problem solved for upload-pack when fetching or cloning but remains for recieve-pack when pushing to remote respository. – andthereitgoes Aug 09 '17 at 16:56
  • @andthereitgoes Strange. Did you have a different error message? – VonC Aug 09 '17 at 19:18
  • Yes. It's about the receive-pack. I get this error WARN -- : gitlab-shell: Attempt to execute disallowed command – andthereitgoes Aug 09 '17 at 21:09
  • @andthereitgoes Strange again, considering it should send `git-receive-pack` as before. This should have worked unless you don't have the right to push. – VonC Aug 09 '17 at 21:10
  • As I said with Git version 2.7.0 for windows with the same SSH key I am able to push. – andthereitgoes Aug 10 '17 at 05:16
  • @andthereitgoes Would it work better with 2.14.1? (https://github.com/git-for-windows/git/releases/tag/v2.14.1.windows.1) – VonC Aug 10 '17 at 21:15
  • I don't know because I couldn't try it as I was unable to clone the repo due to git-upload-pack issue as stated in my original post. now that that was fixed in 14.0.windows.2, cloning worked perfectly but push doesn't work now. it's funny that 2.7.0 works on another winodws machine with same access rights and keys. – andthereitgoes Aug 10 '17 at 21:34
  • I have a omniinstall of gitlab. Where do I find the gitlab-shell.rb with the parce_cmd? – andthereitgoes Aug 10 '17 at 21:39
  • @andthereitgoes Check this path: https://github.com/gitlabhq/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/recipes/gitlab-shell.rb – VonC Aug 11 '17 at 05:13
  • yes I did, but that script doesn't do the parsing of git command – andthereitgoes Aug 11 '17 at 06:15
  • @andthereitgoes Right! Omnibus is not GitLab indeed: https://github.com/gitlabhq/omnibus-gitlab/blob/285495a0d2cc1e1ff80988e654a269c644af62ef/doc/architecture/README.md – VonC Aug 11 '17 at 06:25
  • but there's no parse command in the link that you posted. Any idea? – andthereitgoes Aug 11 '17 at 09:19
  • @andthereitgoes https://github.com/gitlabhq/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/recipes/gitlab-shell.rb#L22 shows: `gitlab_shell_dir = "/opt/gitlab/embedded/service/gitlab-shell"`: do you see gitlab-shell there? – VonC Aug 11 '17 at 09:45
  • great, found it and made the change in `gitlab-shell.rb` but I don't use ruby so I am not sure what are the follow up actions? Do I just restart gitlab and it will interpret the changes or do I need to compile it? Also, in the merge request that you posted, the OP has also made some changes to the `gitlab_shel_spec.rb` file as well. Do I need to make those changes as well? In the same spec file he has used `shared_examples_for` not sure where it is declared as I can't find it. – andthereitgoes Aug 12 '17 at 10:59
  • @andthereitgoes it should be dynamic: no need to restart/compile. – VonC Aug 12 '17 at 11:10
  • what about the `gitlab_shell_spec.rb` changes? – andthereitgoes Aug 12 '17 at 11:52
  • @andthereitgoes Yes, but keep in mind any Git 2.14.x (.1 or .2) means you don't have to do those changes at all. I understand you cannot clone right now, so you need to replicate the changes from https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/159/diffs, including `gitlab_shell_spec.rb` – VonC Aug 12 '17 at 11:55
  • actually cloning works. with gi 2.14.x, I can't do push becase of the receive-pack. So I have to make changes to `gitlab_shell_rb` for `receive-pack` based on the changes in the merge request. – andthereitgoes Aug 12 '17 at 12:18
0

Both Bitbucket Server and Gogs are seeing similar problems.

It appears that something changed in git 2.14.0 (possibly only on Windows) that requires either an update to the products or a fix to git.

BrezzaP
  • 2,463
  • 3
  • 15
  • 10