Git authentication over apache_mod_krb
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://firstname.lastname@example.org/git/myapp.git Initialized empty Git repository in /tmp/myapp/.git/ Password: error: The requested URL returned error: 401 while accessing http://email@example.com/git/myapp.git/info/refs fatal: HTTP request failed
and in apache error logs
- git push to https repository from Intranet application with kerberos authentication
- git-svn dcommit from post-commit with Kerberos
- Kerberos authentication with Git in TFS2013
[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
3 Solutions collect form web for “Git authentication over apache_mod_krb”
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 (
remote-curl: fall back to
Apache servers using
mod_auth_kerbcan 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.
libcurlwill try very hard to use something other than
auth, even over HTTPS.
Basicand something else are offered,
libcurlwill 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.
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.
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:firstname.lastname@example.org > ~/.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 🙂 ).