Git authentication over apache_mod_krb

2019-02-18 04:06发布

问题:

I'm using git repo with git-http-backend. In apache2 I have location what needs authentication for clone and push actions. When I protected it location with AuthType Basic all works is fine, git passes authentication and can clone and push, but if I change type to KerberosV5 git can't access to repo with correctly credentials. If I'm using my browser I have access to location what to protect kerberos.

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-kerb 5.3-5

回答1:

Problem in curl, because git in debian was compiled with curl option ANY_AUTH, and when git client try connect to webserver and first ask it negotiate auth and it can't do it, git don't try basic auth.

That will be more robust, with Git 2.3.1 (Q1/Q2 2015): see commit 4dbe664 by brian m. carlson (bk2204):

remote-curl: fall back to Basic auth if Negotiate fails

Apache servers using mod_auth_kerb can be configured to allow the user to authenticate either using Negotiate (using the Kerberos ticket) or Basic authentication (using the Kerberos password). Often, one will want to use Negotiate authentication if it is available, but fall back to Basic authentication if the ticket is missing or expired.

However, libcurl will try very hard to use something other than Basic auth, even over HTTPS.
If Basic and something else are offered, libcurl will never attempt to use Basic, even if the other option fails.
Teach the HTTP client code to stop trying authentication mechanisms that don't use a password (currently Negotiate) after the first failure, since if they failed the first time, they will never succeed.



回答2:

Problem in curl, because git in debian was compiled with curl option ANY_AUTH, and when git client try connect to webserver and first ask it negotiate auth and it can't do it, git don't try basic auth, because basic is lower security than negotiate. When I try curl --anyauth I can' get data from webserver too, but if I change --basic all works fine, problem in that I can't tell git what auth should use.



回答3:

It's something weird in libcurl, not a problem in Git. There is a workaround. Libcurl doesn't enable any authentication code if you don't pass username and password to the library. This happens if you use negotiate (kerberos) too which doesn't require username and password. The simple solution:

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

x:x is the username and password. You can use any random string there. It's only needed to enable the code path to authentication in libcurl. Then kerberos will work (works for me :) ).