> On Dec 18, 2014, at 5:54 PM, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx': >> 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? > 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. ��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�