Re: git-http-backend auth via Kerberos
On Dec 19, 2014, at 3:16 PM, brian m. carlson
wrote:
>
> On Fri, Dec 19, 2014 at 03:07:20PM +, Dan Langille (dalangil) wrote:
>> Correct, we are trying to avoid that. In addition, there is only https, no
>> http.
>
> I don't think HTTPS versus HTTP matters. I use Kerberos over HTTPS only
> and it works fine.
>
>> 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
>
> That could possibly be due to KrbSaveCredentials.
>
>> For the record, this is the gitweb auth:
>>
>>
>> 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
>
> Does it work if you set this value (KrbMethodK5Passwd on) explicitly in
> the other configuration? That might be sufficient.
No, it does not.
>> 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?
>
> No, I meant the HTTP server, which it looks like from your attempt it
> does. I'm not really sure what the issue is after looking at that,
> although it looks like Git isn't sending the username and password.
> I'll try to look at this a little more this weekend.
If you can, thanks. I’ll be happy to run any tests etc. I’m the second
person here to tackle this and we keep hitting the same block.
cheers
—
Dan Langille
Infrastructure & Operations
Talos Group
Sourcefire, Inc.
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
Re: git-http-backend auth via Kerberos
On Fri, Dec 19, 2014 at 03:07:20PM +, Dan Langille (dalangil) wrote: > Correct, we are trying to avoid that. In addition, there is only https, no > http. I don't think HTTPS versus HTTP matters. I use Kerberos over HTTPS only and it works fine. > 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 That could possibly be due to KrbSaveCredentials. > For the record, this is the gitweb auth: > > > 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 Does it work if you set this value (KrbMethodK5Passwd on) explicitly in the other configuration? That might be sufficient. > > 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? No, I meant the HTTP server, which it looks like from your attempt it does. I'm not really sure what the issue is after looking at that, although it looks like Git isn't sending the username and password. I'll try to look at this a little more this weekend. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: git-http-backend auth via Kerberos
> On Dec 19, 2014, at 10:07 AM, Dan Langille (dalangil) > wrote: > >> 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. > For the record, I tried git 2.2.1 and it gave identical results. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-http-backend auth via Kerberos
> On Dec 19, 2014, at 10:07 AM, Dan Langille (dalangil) > wrote: > >> 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. > For the record, I tried git 2.2.1 and it gave identical results. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-http-backend auth via Kerberos
> On Dec 18, 2014, at 5:54 PM, brian m. carlson > wrote: > > On Thu, Dec 18, 2014 at 10:19:19PM +, 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://d...@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: 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 requirevalid-user > 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.
Re: git-http-backend auth via Kerberos
On Thu, Dec 18, 2014 at 10:19:19PM +, 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://d...@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. 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. When you get that working, it will probably also work for you with git. You can also run git with GIT_CURL_VERBOSE=1 and see the protocol exchange printed out, so you can see what's happening. You'll obviously want to see if the server offers Basic auth as well as Negotiate. 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. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
