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.
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](typicallygit-upload-pack, with the regression git) to determine whether it is a permitted command.So I think it is by design that
gitis rejected whilegit-upload-packis 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-packwas not in thePATH) 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.
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.
来源：https://stackoverflow.com/questions/45538328/cant-clone-on-windows-but-can-clone-on-linux-from-gitlab-server