I have an Azure DevOps project with a couple of Git repos. When I do a git clone from a Command Prompt on the "bad" repo I get the following error message:
Cloning into 'myBadRepo'...
remote: Azure Repos
remote: Found 176 objects to send. (0 ms)
error: RPC failed; curl 56 Failure when receiving data from the peer
Receiving objects: 100% (176/176), 10.22 MiB | 25.46 MiB/s, done.
Resolving deltas: 100% (48/48), done.
Searching Google for curl 56 Failure mostly says that this is an issue with a firewall or proxy. I am on a corporate network, using Cisco AnyConnect as a VPN, but turning that off makes no difference. My machine is also using zScaler for "Internet Security" which I know is messing with the certificates, but I cannot disable it. But I doubt that the firewall, proxy or certs are main the issue, because I can successfully clone a different Git repo from the same Azure DevOps organization and project:
Cloning into 'myWorkingRepo'...
remote: Azure Repos
remote: Found 107 objects to send. (3 ms)
Receiving objects: 100% (107/107), 859.57 KiB | 29.64 MiB/s, done.
Resolving deltas: 100% (35/35), done.
I have tried doing a "shallow clone" as suggested at https://stackoverflow.com/a/66207817/11057678 and increasing the http.postBuffer as suggested at https://stackoverflow.com/a/68097529/11057678 but neither makes any differece.
I turned on verbose mode and tracing, as suggested at https://confluence.atlassian.com/stashkb/git-clone-fails-error-rpc-failed-result-56-http-code-200-693897332.html
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1
I can see that both logs have repeated warnings of Info: schannel: failed to decrypt data, need more data which is concerning, but the "working" repo is cloning successfully, while the "bad" repo has a lot more of these warnings, and after the last set of 647 (!) failed to decrypt messages it shows a closed connection and then the curl 56 Failure:
Info: schannel: server closed abruptly (missing close_notify)
Info: Closing connection 0
channel: shutting down SSL/TLS connection with dev.azure.com port 443
error: RPC failed; curl 56 Failure when receiving data from the peer
Excerpts from the "bad" log is below (the full log is too long to post). Both logs contain the same authorization-related warning and errors, which are not however preventing a clone of the "good" repo. One error in particular is the URL-encoded
The user 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa' is not authorized to access this resource
Where is this user aaaaaaa coming from? I suspect that if I can configure Git and/or the Azure DevOps repo in a way to eliminate these authorization-related warnings and errors, my problems with the "bad" repo will be solved. Hopefully someone can take a look at them and give me some advice or direction, thanks!
"Bad" repo log excerpts:
git clone https://[email protected]/myOrganization/myDevOpsProject/_git/myBadRepo
05:13:49.157466 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
05:13:49.158466 git.c:459 trace: built-in: git clone https://[email protected]/myOrganization/myDevOpsProject/_git/myBadRepo
Cloning into 'myBadRepo'...
05:13:49.180609 run-command.c:654 trace: run_command: git remote-https origin https://[email protected]/myOrganization/myDevOpsProject/_git/myBadRepo
05:13:49.194684 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
05:13:49.195683 git.c:748 trace: exec: git-remote-https origin https://[email protected]/myOrganization/myDevOpsProject/_git/myBadRepo
05:13:49.196685 run-command.c:654 trace: run_command: git-remote-https origin https://[email protected]/myOrganization/myDevOpsProject/_git/myBadRepo
05:13:49.212111 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
05:13:49.220376 http.c:689 == Info: Couldn't find host dev.azure.com in the (nil) file; using defaults
05:13:49.225816 http.c:689 == Info: Trying 13.107.42.20:443...
05:13:49.244824 http.c:689 == Info: Connected to dev.azure.com (13.107.42.20) port 443 (#0)
05:13:49.245003 http.c:689 == Info: schannel: disabled automatic use of client certificate
05:13:49.313976 http.c:636 => Send header, 0000000240 bytes (0x000000f0)
05:13:49.313976 http.c:648 => Send header: GET /myOrganization/myDevOpsProject/_git/myBadRepo/info/refs?service=git-upload-pack HTTP/1.1
05:13:49.313976 http.c:648 => Send header: Host: dev.azure.com
05:13:49.313976 http.c:648 => Send header: User-Agent: git/2.36.0.windows.1
05:13:49.313976 http.c:648 => Send header: Accept: */*
05:13:49.313976 http.c:648 => Send header: Accept-Encoding: deflate, gzip, br, zstd
05:13:49.313976 http.c:648 => Send header: Pragma: no-cache
05:13:49.313976 http.c:648 => Send header: Git-Protocol: version=2
05:13:49.313976 http.c:648 => Send header:
05:13:49.571301 http.c:689 == Info: schannel: failed to decrypt data, need more data
... 8 lines removed ...
05:13:49.672466 http.c:689 == Info: schannel: failed to decrypt data, need more data
05:13:49.672466 http.c:689 == Info: Mark bundle as not supporting multiuse
05:13:49.672466 http.c:636 <= Recv header, 0000000027 bytes (0x0000001b)
05:13:49.672466 http.c:648 <= Recv header: HTTP/1.1 401 Unauthorized
[....]
05:13:49.672466 http.c:648 <= Recv header: WWW-Authenticate: Bearer authorization_uri=https://login.microsoftonline.com/cc808ba9-3e5f-4f13-a70b-5b65bf454995
05:13:49.672466 http.c:636 <= Recv header, 0000000071 bytes (0x00000047)
05:13:49.672466 http.c:648 <= Recv header: WWW-Authenticate: Basic realm="https://tfsprodcus6.visualstudio.com/"
05:13:49.672466 http.c:636 <= Recv header, 0000000033 bytes (0x00000021)
[...]
05:13:49.672466 http.c:648 <= Recv header: X-FRAME-OPTIONS: SAMEORIGIN
05:13:49.672466 http.c:636 <= Recv header, 0000000059 bytes (0x0000003b)
05:13:49.672466 http.c:648 <= Recv header: X-TFS-FedAuthRealm: https://tfsprodcus6.visualstudio.com/
05:13:49.672466 http.c:636 <= Recv header, 0000000059 bytes (0x0000003b)
05:13:49.672466 http.c:648 <= Recv header: X-TFS-FedAuthIssuer: https://dev.azure.com/myOrganization/
05:13:49.672466 http.c:636 <= Recv header, 0000000073 bytes (0x00000049)
05:13:49.672466 http.c:648 <= Recv header: X-VSS-AuthorizationEndpoint: https://vssps.dev.azure.com/myOrganization/
05:13:49.672466 http.c:636 <= Recv header, 0000000060 bytes (0x0000003c)
05:13:49.672466 http.c:648 <= Recv header: X-VSS-ResourceTenant: cc808ba9-3e5f-4f13-a70b-5b65bf454995
05:13:49.672466 http.c:636 <= Recv header, 0000000710 bytes (0x000002c6)
05:13:49.672466 http.c:648 <= Recv header: X-TFS-SoapException: <?xml version="1.0" encoding="utf-8"?>soap:Receiver UnauthorizedRequestException TF400813: The user 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa' is not authorized to access this resource. CodePudding user response：
Where is this user
aaaaaaacoming from?
It is (as illustrated in Azure/azure-devops-cli-extension) the _ANONYMOUS_USER_ID.
The error message just means an anonymous user cannot access this repository (which is expected).
Since even a shallow clone does not work, I would, for testing:
- do an Azure pipeline to see if the sync source (ie the clone/pull) step works there
- or in a similar pipeline, get an
git archive(HEAD commit content as a zip), in order to make a new Azure Devops repository and try to push that content to it: that would validate if something in that content is problematic. See this as an example.
CodePudding user response：
It's definitely a Zscaler issue. I had exactly the same issue (the bigger is the repo, the higher is the probability to have the curl error but not always) and found the explanation in this answer
The only solution is to use the Zscaler certificate.