[英]Can't clone on windows but can clone on linux from Gitlab server
我正在嘗試通過SSH從遠程Gitlab服務器克隆存儲庫。 我正在使用Gitlab CE version 9.3.9 755bb71
和TortoiseGIT version 2.5.0
和git (for windows) version 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
當我在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.
我花了十多個小時來嘗試調試所有內容,但我不確定有什么區別或問題到底出在哪里。 我也嘗試將以下內容添加到TortoiseGit的本地.gitconfig
文件中,但這沒有任何改變。
[remote "origin"]
uploadpack = git-upload-pack
最后,通過HTTPS克隆相同的存儲庫工作正常,而使用用戶名/密碼則沒有任何問題。
注意:我只是升級到Windows的Git 2.14.0 ...而ssh網址都無法正常工作:
> git ls-remote
GitLab: Disallowed command
fatal: Could not read from remote repository.
( origin
是ssh網址)
另一個副作用: git-for-windows / git問題1258
fatal: protocol error: bad line length character: Not
好像BitBucket看着
argv[0]
(通常是git-upload-pack
,帶有回歸git)來確定它是否是允許的命令。因此,我認為這是設計使
git
被拒絕而git-upload-pack
不被拒絕的原因。
關於GitLab的錯誤的同類: gitlab-ce問題36028 。
待處理的合並請求 在檢測到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
在Windows的Git端,一個修復程序正在進行中: 參見commit 0f33428
還原“ git_connect:首選Git的內建函數而不是虛線形式”
似乎此更改(旨在修復當
git-upload-pack
不在PATH
時與本地存儲庫交互的測試)在SSH訪問中逐漸消失。
用於Windows 2.14.0(2)的Git正在開發中,並且在此編輯時的30分鍾前剛剛發布(2017-08-07T11:05:34Z UTC)。
原始答案
如果key1
與您的/path/to/.ssh/key
相同,並且確實標識了John Doe,則這意味着John Doe無權訪問該存儲庫( 如此處所示 )。
檢查key2是否與其他用戶關聯。
如果兩個鍵都引用相同的用戶,那么這將是一個本地配置問題(如本答案所示 )。 還要檢查您的TortoiseGit是否使用與測試中相同的密鑰:
set "GIT_COMMAND_SSH=ssh -v"
# launch TortoiseGit from that CMD session
然后,您將看到使用ssh url克隆存儲庫時正在使用的TortoiseGit。 您可能需要定義一個.ssh/config
文件 。
Bitbucket Server和Gogs都遇到類似的問題。
似乎在git 2.14.0中(可能僅在Windows上)發生了更改,需要對產品進行更新或對git進行修復。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.