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://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

  • git-svn dcommit from post-commit with Kerberos
  • Kerberos authentication with Git in TFS2013
  • git push to https repository from Intranet application with kerberos authentication
  • 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 (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
    .

    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: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 🙂 ).

    Git Baby is a git and github fan, let's start git clone.