Re: git-http-backend auth via Kerberos

From: Dan Langille (dalangil) <dalangil@cisco.com>
Date: Dec 19, 2014, 15:07 UTC
Message-ID: <D562883B-47D7-4569-B1BB-84BFBDCBA93A@cisco.com>
In-Reply-To: <20141218225418.GA84625@vauxhall.crustytoothpaste.net>

Show 15 quoted lines

> On Dec 18, 2014, at 5:54 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote:
> 
> On Thu, Dec 18, 2014 at 10:19:19PM +0000, Dan Langille (dalangil) wrote:
>> This is what happens without a valid ticket:
>> 
>> $ git clone https://us.example.com/git/clamav-bytecode-compiler
>> Cloning into 'clamav-bytecode-compiler'...
>> Username for 'https://us.example.com': dan
>> Password for 'https://dan@us.example.com': 
>> fatal: Authentication failed for 'https://us.example.com/git/clamav-bytecode-compiler/'
> 
> So there are two ways to do this.  One is allowing users to clone
> without any credentials, which I take it you are trying to avoid.  If
> that *is* what you're going for, I can provide you with my Apache
> configuration, which does allow that.

Correct, we are trying to avoid that.  In addition, there is only https, no http.

> What I would recommend is going to
> https://us.example.com/git/clamav-bytecode-compiler/info/refs in a web
> browser without a ticket, and see if it prompts you for a username and
> password.

To be clear, for the following tests, there is no Kerberos ticket.

I tried that URL using three different browsers. Each time I am prompted for a username & password. After entering valid credentials, I get:

Chrome: No data received. Unable to load the webpage because the server
sent no data. Error code: ERR_EMPTY_RESPONSE

With Firefox: The connection was reset

Safari: Safari Can’t Open The Page

However, I did stumble across something which seems promising.

After the above failures, if I then browse to /gitweb/ (where I see expected results) and then go to the info/refs URL you supplied, I see data such as this:

   fe068a8ae55cea4bb90e2cc714107f4c5389d516	refs/heads/0.96.x
   d384a963980e9b40e34dea80eac280cf2d4b7c73	refs/heads/0.97.x

Conclusion: there is something in the /gitweb auth which is succeeding and then
allowing /git to work

For the record, this is the gitweb auth:

<Location /gitweb>
  SSLOptions +StdenvVars
  Options +ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch

  AuthType           Kerberos
  AuthName           “us.example.com"
  KrbAuthRealms      us.example.com
  KrbServiceName     HTTP/us.example.com
  Krb5Keytab         /usr/local/etc/apache22/repo-test.keytab
  KrbMethodNegotiate on
  KrbMethodk5Passwd  on

  require            valid-user
</Location>

>  When you get that working, it will probably also work for you
> with git.

Not yet...

> 
> You can also run git with GIT_CURL_VERBOSE=1 and see the protocol
> exchange printed out, so you can see what's happening.

That attempt is shown here: http://dpaste.com/04RG37E.txt

> You'll obviously
> want to see if the server offers Basic auth as well as Negotiate.

I’m not up on my knowledge here.  You mean the Kerberos server?

Show 8 quoted lines

> You might also try specifying KrbMethodK5Passwd on explicitly.  I don't
> happen to use that option (I use Kerberos to avoid passwords altogether)
> so that might work for you.
> 
> I don't know what version of git you're using, but some older versions
> will still prompt for a password whenever authentication fails.
> Therefore, just because you're getting a password prompt doesn't mean
> that providing a password will necessarily work.

How old is older?

$ git --version git version 1.9.3 (Apple Git-50)

Might that be it?  Hmmm.