Can't clone on windows but can clone on linux from Gitlab server - linux

Question

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.

Answer 1

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.

Answer 2

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.