Geek Answers Handbook

Git authentication by apache_mod_krb

I am using git repo with git-http-backend. In apache2, I have a place that requires authentication for cloning and push actions. When I protected its location with AuthType Basic everything worked fine, git is authenticated and can clone and click, but if I change the type to KerberosV5 git, then I cannot access the repo with the correct credentials. If I use my browser, I have access to the location that is needed to protect the keberos.

git clone http:// user@mydomain.com /git/myapp.git Initialized empty Git repository in /tmp/myapp/.git/ Password: error: The requested URL returned error: 401 while accessing http:// user@mydomain.com /git/myapp.git/info/refs fatal: HTTP request failed

and in apache error logs

 [Fri Aug 06 17:15:50 2010] [debug] src/mod_auth_kerb.c(1579): [client 192.168.12.153] kerb_authenticate_user entered with user (NULL) and auth_type KerberosV5 [Fri Aug 06 17:15:50 2010] [debug] src/mod_auth_kerb.c(1579): [client 192.168.12.153]kerb_authenticate_user entered with user (NULL) and auth_type KerberosV5

git -core 1: 1.7.1-1 ~ bpo50 + 1 apache2 2.2.9-10 + lenny8 libapache2-mod-auth-curb 5.3-5

+4
source share
3 answers

The problem is in curl, because git in debian was compiled with the curl parameter ANY_AUTH , and when the git client tries to connect to the web server and first ask it to negotiate auth, and it cannot do this, git don’t try basic auth.

This will be more reliable with git 2.3.1 (Q1 / Q2 2015): see commit 4dbe664 brian m. carlson ( bk2204 ) :

remote-curl : go back to Basic auth if Negotiate failed

Apache servers using mod_auth_kerb can be configured to allow the user to authenticate using either Negotiate (using a Kerberos ticket) or Basic authentication (using a Kerberos password). Often everyone wants to use authentication in negotiations if it is available, but backtrack to basic authentication if the ticket is missing or expired.

However, libcurl will try very hard to use something other than Basic auth, even through HTTPS.
If Basic and something else is offered, libcurl will never try to use Basic , even if the other option failed.
Learn the HTTP client code to stop trying to authenticate mechanisms that do not use a password (currently Negotiate ) after the first failure, because if they failed for the first time, they will never succeed .

+3
source

The problem is in curl, because git in debian was compiled with the curl parameter ANY_AUTH, and when the git client tries to connect to the web server and first ask it to negotiate auth, and it will not be able to do this, git do not try basic auth, because the basic level security is lower than negotiation. When I try to curl --anyauth, I can also get data from the web server, but if I change - basic everything works fine, the problem is that I cannot tell git what auth should use.

+1
source

This is something weird in libcurl, not a problem in Git. There is a workaround. Libcurl does not include the authentication code unless you pass the username and password to the library. This happens if you also use negotiations (kerberos), which do not require a username and password. A simple solution:

 echo http://x: x@git.example.com > ~/.git-credentials git config --global credential.helper store

x: x - username and password. You can use any random string. This is only necessary to enable the authentication path in libcurl. Then kerberos will work (works for me :)).

+1
source

More articles:


All Articles