Re: forcing a user@ into the URL if not present
On Thu, Apr 30, 2015 at 4:23 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Thu, Apr 30, 2015 at 04:14:12PM -0400, Dan Langille wrote: Would this question be better suited for another list? Nope, this is the place to go. On Wed, Apr 22, 2015 at 4:06 PM, Dan Langille dlangi...@sourcefire.com wrote: Hello, I'm using git 2.3.2 with Kerberos for authentication and gito-lite for authorization. This works: $ git clone https://dvl@ repo.example.org/git/testing Cloning into 'testing'... warning: You appear to have cloned an empty repository. Checking connectivity... done. My goal: have it work without supplying dvl@ as shown here: $ git clone https://repo.example.org/git/testing Cloning into 'testing'... Username for 'https://repo.example.org': I don't want to be prompted for a password. I want Kerberos to kick in. Following http://git-scm.com/docs/gitcredentials, the following seems to have nil effect. Anyone used this feature already? git config --global credential.https://repo.example.org.username dvl $ cat ~/.gitconfig [credential https://repo.example.org;] username = dvl [http] sslCAInfo = /usr/local/etc/trusted-certificates.pem With the above, I still get prompted for a password Given my use of Kerberos for authorization, is this option feasible? Not at the present time. The only time that the credential API is invoked is if it prompts for a password, and by that point you've fallen back to Basic authentication. Should I be taking a different approach? If you want it to work only with Kerberos, then any username in the URL is fine, as libcurl doesn't care. That is what I found during testing. So long as I put a username in the URL, Kerberos worked and all authentication occurred as expected. One thing you could try is to make your URL https://g...@repo.example.org and then use git config --global credential.https://g...@repo.example.org.username dvl and see if it does the right thing for both Kerberos and Basic auth. It would be sort of a hack, but it might work. It asks for a password, and for the correct user: Password for 'https://d...@repo.example.org': Thanks Brian, for this, and your other help. I appreciate it. -- Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc. -- 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
forcing a user@ into the URL if not present
Hello, I'm using git 2.3.2 with Kerberos for authentication and gito-lite for authorization. This works: $ git clone https://dvl@ repo.example.org/git/testing Cloning into 'testing'... warning: You appear to have cloned an empty repository. Checking connectivity... done. My goal: have it work without supplying dvl@ as shown here: $ git clone https://repo.example.org/git/testing Cloning into 'testing'... Username for 'https://repo.example.org': I don't want to be prompted for a password. I want Kerberos to kick in. Following http://git-scm.com/docs/gitcredentials, the following seems to have nil effect. Anyone used this feature already? git config --global credential.https://repo.example.org.username dvl $ cat ~/.gitconfig [credential https://repo.example.org;] username = dvl [http] sslCAInfo = /usr/local/etc/trusted-certificates.pem With the above, I still get prompted for a password Given my use of Kerberos for authorization, is this option feasible? Should I be taking a different approach? Thank you. -- Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc. -- 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: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Feb 25, 2015, at 3:59 PM, Dan Langille (dalangil) dalan...@cisco.com
wrote:
On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil) dalan...@cisco.com
wrote:
On Feb 19, 2015, at 3:35 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote:
I just built from ‘master’, on FreeBSD 9.3:
cd ~/src
git clone https://github.com/git/git.git
cd git
gmake
Then tried ~/src/git/git clone https://OUR_REPO
It cores too, and I see: git-remote-https.core
Can you compile with debugging symbols and provide a backtrace? I'm not
seeing any such behavior on my end, and I'm not sure whether it's my
patch or something else that might be present in master.
The problem originally occurred under VMware Fusion and I’m unable to get a
backtrace from it.
I suspect memory constraints are a factor. There’s only 5GB RAM available
to this VM.
I have tried in another VM and that succeeds. All good there. It has 40GB
RAM.
I am going to try this on a third system. At present, we’re just 50/50 on
success.
We have made progress I think.
With stock git:
tl;dr: 1 - with a ticket, you get prompted, but hitting ENTER succeeds.
2 - without a ticket, nothing works
With patched git:
tl;dr: 1 - with a ticket,entering credentials, SUCCEEDS; just hit enter,
failure
If I have a valid ticket, why am I being prompted for credentials?
It appears patched git always wants credentials entered and ignores the valid
ticket.
2 - without a ticket, entering credentials, SUCCEEDS
Here is my test, with a valid kerberos ticket:
$ git clone https://git.example.com/git/clamav-bytecode-compiler
Cloning into 'clamav-bytecode-compiler'...
Username for 'https://git.example.com':
Password for 'https://git.example.com':
^Cmote: Counting objects: 224546
$
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Tue, Mar 10, 2015 at 06:05:46PM +, Dan Langille (dalangil) wrote: We have made progress I think. With stock git: tl;dr: 1 - with a ticket, you get prompted, but hitting ENTER succeeds. 2 - without a ticket, nothing works With patched git: tl;dr: 1 - with a ticket,entering credentials, SUCCEEDS; just hit enter, failure If I have a valid ticket, why am I being prompted for credentials? libcurl won't even attempt authentication if you don't have a username specified. I know that the web server should be able to figure it out from your credentials, so it shouldn't matter what username you provide. This is an unfortuate quirk of lib curl. I understand. Also, are you using 2.3.0, or one of the earlier patched versions? That might affect how it works. I am using git-2.3.0 It appears patched git always wants credentials entered and ignores the valid ticket. So what I think is happening is that you didn't specify a username, but git got a 401, so it prompted. Now it actually attempts to use the password you provided, whereas before it did not. Does it work with a ticket if you specify a username, as in the following URL? https://b...@git.crustytoothpaste.net/git/bmc/homedir.git Yes, that does work. Our project is 98% of the way there now. I looked at both libcurl and git environment variables to see if there was a way to specify the user without putting it in the URL. I didn’t see one. My next step is the git configuration, either server or client. Do you know if I should stop looking now because it’s not there? Thank you for your help in getting us this far. This helps us tremendously. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Mar 11, 2015, at 5:59 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Mar 11, 2015 at 07:33:05PM +, Dan Langille (dalangil) wrote: On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: Does it work with a ticket if you specify a username, as in the following URL? https://b...@git.crustytoothpaste.net/git/bmc/homedir.git Yes, that does work. Our project is 98% of the way there now. I looked at both libcurl and git environment variables to see if there was a way to specify the user without putting it in the URL. I didn’t see one. My next step is the git configuration, either server or client. Do you know if I should stop looking now because it’s not there? You might try looking at git config --help. It looks like there's a credential.username option that might do what you want. Brian et al, Thank you for your help and patience with this. It is appreciated. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil) dalan...@cisco.com wrote: On Feb 19, 2015, at 3:35 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote: I just built from ‘master’, on FreeBSD 9.3: cd ~/src git clone https://github.com/git/git.git cd git gmake Then tried ~/src/git/git clone https://OUR_REPO It cores too, and I see: git-remote-https.core Can you compile with debugging symbols and provide a backtrace? I'm not seeing any such behavior on my end, and I'm not sure whether it's my patch or something else that might be present in master. The problem originally occurred under VMware Fusion and I’m unable to get a backtrace from it. I suspect memory constraints are a factor. There’s only 5GB RAM available to this VM. I have tried in another VM and that succeeds. All good there. It has 40GB RAM. I am going to try this on a third system. At present, we’re just 50/50 on success. We have made progress I think. With stock git: tl;dr: 1 - with a ticket, you get prompted, but hitting ENTER succeeds. 2 - without a ticket, nothing works With patched git: tl;dr: 1 - with a ticket,entering credentials, SUCCEEDS; just hit enter, failure 2 - without a ticket, entering credentials, SUCCEEDS Here is my test, with a valid kerberos ticket: $ git clone https://git.example.com/git/clamav-bytecode-compiler Cloning into 'clamav-bytecode-compiler'... Username for 'https://git.example.com': Password for 'https://git.example.com': ^Cmote: Counting objects: 224546 $
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Feb 19, 2015, at 3:35 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote: I just built from ‘master’, on FreeBSD 9.3: cd ~/src git clone https://github.com/git/git.git cd git gmake Then tried ~/src/git/git clone https://OUR_REPO It cores too, and I see: git-remote-https.core Can you compile with debugging symbols and provide a backtrace? I'm not seeing any such behavior on my end, and I'm not sure whether it's my patch or something else that might be present in master. The problem originally occurred under VMware Fusion and I’m unable to get a backtrace from it. I suspect memory constraints are a factor. There’s only 5GB RAM available to this VM. I have tried in another VM and that succeeds. All good there. It has 40GB RAM. I am going to try this on a third system. At present, we’re just 50/50 on success. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Feb 17, 2015, at 6:36 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding to and have been using it for your daily Git needs ;-) I believe it is queued on the 'next' branch so that others like you who need the change can verify the improvements, and others unlike you who do not need the change can make sure the change does not cause unintended consequences. Is this the patch in question? https://github.com/git/git/commit/4dbe66464b4fd695c5989cc272fa0edd6475037c I ask because previous versions of the patch acted against http.h as well and my failure with it. Could I expect that patch work against 2.3.0? It applies cleanly, compiles, but cores when I try a ‘git clone’. Unmatched 2.3.0 succeeds. It already is in 'master', so please holler if things break with that version. I just built from ‘master’, on FreeBSD 9.3: cd ~/src git clone https://github.com/git/git.git cd git gmake Then tried ~/src/git/git clone https://OUR_REPO It cores too, and I see: git-remote-https.core — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding to and have been using it for your daily Git needs ;-) I believe it is queued on the 'next' branch so that others like you who need the change can verify the improvements, and others unlike you who do not need the change can make sure the change does not cause unintended consequences. Is this the patch in question? https://github.com/git/git/commit/4dbe66464b4fd695c5989cc272fa0edd6475037c I ask because previous versions of the patch acted against http.h as well and my failure with it. Could I expect that patch work against 2.3.0? It applies cleanly, compiles, but cores when I try a ‘git clone’. Unmatched 2.3.0 succeeds.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding to and have been using it for your daily Git needs ;-) Patch v2 has been used in our test environment with success. I got diverted to other projects before I could test Patch v3. I believe it is queued on the 'next' branch so that others like you who need the change can verify the improvements, and others unlike you who do not need the change can make sure the change does not cause unintended consequences. Thank you. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
I did not test this patch. Is that holding up a commit?
—
Dan Langille
Infrastructure Operations
Talos Group
Sourcefire, Inc.
On Jan 7, 2015, at 7:29 PM, brian m. carlson sand...@crustytoothpaste.net
wrote:
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.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
Signed-off-by: Jeff King p...@peff.net
---
Peff's original change was to get_curl_handle; however, we retry the
second time with the same slot and we may not call get_curl_handle
again, so I had to move that change to get_active_slot. This has been
tested pushing with both Negotiate and Basic against an HTTPS server
both when info/refs was protected and when it was not.
http.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/http.c b/http.c
index 040f362..44b130c 100644
--- a/http.c
+++ b/http.c
@@ -62,6 +62,9 @@ static const char *user_agent;
static struct credential cert_auth = CREDENTIAL_INIT;
static int ssl_cert_password_required;
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+static unsigned long http_auth_methods = CURLAUTH_ANY;
+#endif
static struct curl_slist *pragma_header;
static struct curl_slist *no_pragma_header;
@@ -580,6 +583,9 @@ struct active_request_slot *get_active_slot(void)
curl_easy_setopt(slot-curl, CURLOPT_UPLOAD, 0);
curl_easy_setopt(slot-curl, CURLOPT_HTTPGET, 1);
curl_easy_setopt(slot-curl, CURLOPT_FAILONERROR, 1);
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH, http_auth_methods);
+#endif
if (http_auth.password)
init_curl_http_auth(slot-curl);
@@ -870,6 +876,9 @@ int handle_curl_result(struct slot_results *results)
credential_reject(http_auth);
return HTTP_NOAUTH;
} else {
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ http_auth_methods = ~CURLAUTH_GSSNEGOTIATE;
+#endif
return HTTP_REAUTH;
}
} else {
@@ -986,6 +995,7 @@ static void extract_content_type(struct strbuf *raw,
struct strbuf *type,
strbuf_addstr(charset, ISO-8859-1);
}
+
/* http_request() targets */
#define HTTP_REQUEST_STRBUF 0
#define HTTP_REQUEST_FILE 1
--
2.2.1.209.g41e5f3a
Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails
On Jan 5, 2015, at 6:53 PM, brian m. carlson sand...@crustytoothpaste.net
wrote:
On Mon, Jan 05, 2015 at 09:23:32PM +, Dan Langille (dalangil) wrote:
I have tried both patches. Neither succeeds here. I patched git version
2.2.1 but I don’t think that affects this.
You are patching the client side, correct? That's the side that needs
patching here.
Yes, I am.
Just so the list knows, I will be sending a reroll to the existing patch, but
the patches I've posted do indeed work in my testing.
I appreciate the patches. I blame something here.
The patches don’t t apply cleanly to git-2.2.1 or to the latest git source I
just cloned. I had to copy/paste some two chunks in http.c and everything in
remote-curl.c.
Looking at the source, the place to patch is there, just on a different line
number.
[dvl@porter93 /usr/ports/devel/git/work/git-2.2.1]$ sudo patch ~dvl/patch2.txt
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/http.c b/http.c
|index 040f362..815194d 100644
|--- a/http.c
|+++ b/http.c
--
Patching file http.c using Plan A...
Hunk #1 succeeded at 62.
Hunk #2 succeeded at 988 with fuzz 2.
Hunk #3 failed at 1047.
Hunk #4 failed at 1154.
2 out of 4 hunks failed--saving rejects to http.c.rej
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/http.h b/http.h
|index 473179b..71943d3 100644
|--- a/http.h
|+++ b/http.h
--
Patching file http.h using Plan A...
Hunk #1 succeeded at 98 with fuzz 2.
Hunk #2 succeeded at 114.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/remote-curl.c b/remote-curl.c
|index dd63bc2..4ca5447 100644
|--- a/remote-curl.c
|+++ b/remote-curl.c
--
Patching file remote-curl.c using Plan A...
Hunk #1 failed at 467.
Hunk #2 failed at 513.
Hunk #3 failed at 538.
Hunk #4 failed at 625.
4 out of 4 hunks failed--saving rejects to remote-curl.c.rej
done
Before I flood the list with debug runs, I wanted to make sure I was testing
with an appropriate configuration:
Location /git
SSLOptions +StdenvVars
Options +ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
# By default, allow access to anyone.
Order allow,deny
Allow from All
# Enable Kerberos authentication using mod_auth_kerb.
AuthType Kerberos
AuthName “us.example.org
KrbAuthRealms us.example.org
# I have tried both with and without the following line:
KrbServiceName HTTP/us.example.org
Krb5Keytab /usr/local/etc/apache22/repo-test.keytab
KrbMethodNegotiate on
KrbSaveCredentials on
KrbVerifyKDC on
KrbServiceName Any
# I have tried with and without this line:
KrbMethodk5Passwd on
Require valid-user
/Location
I'm not sure why it's not working for you. Here's a snippet from my config:
SetEnv GIT_HTTP_EXPORT_ALL 1
SetEnv REMOTE_USER $REDIRECT_REMOTE_USER
AuthType Kerberos
AuthName Kerberos Login
KrbMethodNegotiate on
KrbMethodK5Passwd off
KrbAuthRealms CRUSTYTOOTHPASTE.NET
Krb5Keytab /etc/krb5.apache.keytab
When I was testing, I set KrbMethodK5Passwd to on and it did in fact work.
I'm using Debian's Apache 2.4.10-9 with mod_auth_kerb 5.4-2.2.
That didn’t seem to help, but perhaps the patching is the issue.
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails
On Jan 6, 2015, at 10:31 AM, Dan Langille (dalangil) dalan...@cisco.com wrote: On Jan 5, 2015, at 6:53 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Mon, Jan 05, 2015 at 09:23:32PM +, Dan Langille (dalangil) wrote: I have tried both patches. Neither succeeds here. I patched git version 2.2.1 but I don’t think that affects this. You are patching the client side, correct? That's the side that needs patching here. Yes, I am. Just so the list knows, I will be sending a reroll to the existing patch, but the patches I've posted do indeed work in my testing. I appreciate the patches. I blame something here. The patches don’t t apply cleanly to git-2.2.1 or to the latest git source I just cloned. I had to copy/paste some two chunks in http.c and everything in remote-curl.c. NOTE: I now realize these problems are caused by tabs being converted to spaces when downloading the patch. I’m going to test again.
Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails
On Jan 6, 2015, at 10:31 AM, Dan Langille (dalangil) dalan...@cisco.com
wrote:
On Jan 5, 2015, at 6:53 PM, brian m. carlson sand...@crustytoothpaste.net
wrote:
On Mon, Jan 05, 2015 at 09:23:32PM +, Dan Langille (dalangil) wrote:
I have tried both patches. Neither succeeds here. I patched git version
2.2.1 but I don’t think that affects this.
You are patching the client side, correct? That's the side that needs
patching here.
Yes, I am.
Just so the list knows, I will be sending a reroll to the existing patch,
but the patches I've posted do indeed work in my testing.
I appreciate the patches. I blame something here.
The patches don’t t apply cleanly to git-2.2.1 or to the latest git source I
just cloned. I had to copy/paste some two chunks in http.c and everything in
remote-curl.c.
I tried again, with a proper copy of your patch. Cleanly patched versions of
git 2.2.1 and from
a recent clone of the repo both give 'Authentication failed’ when doing a clone
without a ticket.
I’m sure there’s something here which is at fault.
Here is the client side debugging. Is this what is expected? Tested with a
clone of git from this morning.
[dan@porter93 ~/tmp/tmp]$ ~/src/git/git clone
https://us.example.org/git/clamav-bytecode-compiler
Cloning into 'clamav-bytecode-compiler'...
warning: templates not found /usr/home/dan/share/git-core/templates
* Couldn't find host us.example.org in the .netrc file; using defaults
* Hostname was NOT found in DNS cache
* Trying 10.0.0.1...
* Connected to us.example.org (10.0.0.1) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none
* SSL connection using TLSv1.0 / DHE-RSA-CAMELLIA256-SHA
* Server certificate:
*subject: REDACTED
*start date: REDACTED
*expire date: REDACTED
*issuer: REDACTED
*SSL certificate verify result: self signed certificate in certificate
chain (19), continuing anyway.
GET /git/clamav-bytecode-compiler/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/2.2.1.212.gc5b9256.dirty
Host: us.example.org
Accept: */*
Accept-Encoding: gzip
Pragma: no-cache
HTTP/1.1 401 Authorization Required
Date: Tue, 06 Jan 2015 16:02:38 GMT
Server: Apache
WWW-Authenticate: Negotiate
Content-Length: 401
Content-Type: text/html; charset=iso-8859-1
* Connection #0 to host us.example.org left intact
Username for 'https://us.example.org':
Password for 'https://d...@us.example.org':
* Couldn't find host us.example.org in the .netrc file; using defaults
* Connection 0 seems to be dead!
* Closing connection 0
* Hostname was found in DNS cache
* Trying 10.0.0.1...
* Connected to us.example.org (10.0.0.1) port 443 (#1)
* successfully set certificate verify locations:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none
* SSL re-using session ID
* SSL connection using TLSv1.0 / DHE-RSA-CAMELLIA256-SHA
* Server certificate:
*subject: REDACTED
*start date: REDACTED
*expire date: REDACTED
*issuer: REDACTED
*SSL certificate verify result: self signed certificate in certificate
chain (19), continuing anyway.
GET /git/clamav-bytecode-compiler/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/2.2.1.212.gc5b9256.dirty
Host: us.example.org
Accept: */*
Accept-Encoding: gzip
Pragma: no-cache
HTTP/1.1 401 Authorization Required
Date: Tue, 06 Jan 2015 16:02:48 GMT
Server: Apache
WWW-Authenticate: Negotiate
Content-Length: 401
Content-Type: text/html; charset=iso-8859-1
* Connection #1 to host us.example.org left intact
fatal: Authentication failed for
'https://us.example.org/git/clamav-bytecode-compiler/'
[dan@porter93 ~/tmp/tmp]$
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [PATCH] remote-curl: fall back to Basic auth if Negotiate fails.
On Dec 26, 2014, at 11:01 PM, brian m. carlson sand...@crustytoothpaste.net
wrote:
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.
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.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
I was able to reproduce the problem on my server. This fixes the
problem for me both when info/refs requires authentication and when it
does not. Dan, please try and see if this fixes the problem for you.
Has the patch changed since originally posted? Is there a newer one I should
try instead?
Thank you for your work on this, I will test this today.
—
Dan Langille
Infrastructure Operations
Talos Group
Sourcefire, Inc.
I'm not clear on whether NTLM is a passwordless authentication method.
Since I don't use Windows or NTLM, I can't test it, but if it is, just
adding it to HTTP_AUTH_PASSWORDLESS should be sufficient.
http.c| 14 ++
http.h| 5 -
remote-curl.c | 13 -
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/http.c b/http.c
index 040f362..e3e4c65 100644
--- a/http.c
+++ b/http.c
@@ -986,6 +986,16 @@ static void extract_content_type(struct strbuf *raw,
struct strbuf *type,
strbuf_addstr(charset, ISO-8859-1);
}
+void disable_passwordless_auth(struct active_request_slot *slot)
+{
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+#define HTTP_AUTH_PASSWORDLESS (CURLAUTH_GSSNEGOTIATE)
+ curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH,
+ CURLAUTH_ANY ~HTTP_AUTH_PASSWORDLESS);
+#endif
+}
+
+
/* http_request() targets */
#define HTTP_REQUEST_STRBUF 0
#define HTTP_REQUEST_FILE 1
@@ -1035,6 +1045,9 @@ static int http_request(const char *url,
curl_easy_setopt(slot-curl, CURLOPT_HTTPHEADER, headers);
curl_easy_setopt(slot-curl, CURLOPT_ENCODING, gzip);
+ if (options-no_passwordless_auth)
+ disable_passwordless_auth(slot);
+
ret = run_one_slot(slot, results);
if (options options-content_type) {
@@ -1139,6 +1152,7 @@ static int http_request_reauth(const char *url,
}
credential_fill(http_auth);
+ options-no_passwordless_auth = 1;
return http_request(url, result, target, options);
}
diff --git a/http.h b/http.h
index 473179b..fc42bf5 100644
--- a/http.h
+++ b/http.h
@@ -98,6 +98,8 @@ extern int handle_curl_result(struct slot_results *results);
int run_one_slot(struct active_request_slot *slot,
struct slot_results *results);
+void disable_passwordless_auth(struct active_request_slot *slot);
+
#ifdef USE_CURL_MULTI
extern void fill_active_slots(void);
extern void add_fill_function(void *data, int (*fill)(void *));
@@ -138,7 +140,8 @@ extern char *get_remote_object_url(const char *url, const
char *hex,
/* Options for http_get_*() */
struct http_get_options {
unsigned no_cache:1,
- keep_error:1;
+ keep_error:1,
+ no_passwordless_auth:1;
/* If non-NULL, returns the content-type of the response. */
struct strbuf *content_type;
diff --git a/remote-curl.c b/remote-curl.c
index dd63bc2..89bf4ea 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -369,6 +369,8 @@ struct rpc_state {
struct strbuf result;
unsigned gzip_request : 1;
unsigned initial_buffer : 1;
+ /* Automatic authentication didn't work, so don't try it again. */
+ unsigned no_passwordless_auth : 1;
};
static size_t rpc_out(void *ptr, size_t eltsize,
@@ -467,6 +469,9 @@ static int probe_rpc(struct rpc_state *rpc, struct
slot_results *results)
curl_easy_setopt(slot-curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(slot-curl, CURLOPT_FILE, buf);
+ if (rpc-no_passwordless_auth)
+ disable_passwordless_auth(slot);
+
err = run_slot(slot, results);
curl_slist_free_all(headers);
@@ -510,8 +515,10 @@ static int post_rpc(struct rpc_state *rpc)
do {
err = probe_rpc(rpc, results);
- if (err == HTTP_REAUTH)
+ if (err == HTTP_REAUTH) {
credential_fill(http_auth);
+ rpc-no_passwordless_auth = 1;
+ }
} while (err == HTTP_REAUTH);
if (err != HTTP_OK)
return -1;
@@ -533,6 +540,9 @@ retry:
curl_easy_setopt(slot-curl, CURLOPT_URL, rpc-service_url
Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails
I’ve found the latest patch. Trying this now. Thanks.
—
Dan Langille
Infrastructure Operations
Talos Group
Sourcefire, Inc.
On Jan 1, 2015, at 2:56 PM, brian m. carlson sand...@crustytoothpaste.net
wrote:
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.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
http.c| 16
http.h| 3 +++
remote-curl.c | 11 ++-
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/http.c b/http.c
index 040f362..815194d 100644
--- a/http.c
+++ b/http.c
@@ -62,6 +62,8 @@ static const char *user_agent;
static struct credential cert_auth = CREDENTIAL_INIT;
static int ssl_cert_password_required;
+/* Should we allow non-password-based authentication (e.g. GSSAPI)? */
+int http_passwordless_auth = 1;
static struct curl_slist *pragma_header;
static struct curl_slist *no_pragma_header;
@@ -986,6 +988,16 @@ static void extract_content_type(struct strbuf *raw,
struct strbuf *type,
strbuf_addstr(charset, ISO-8859-1);
}
+void disable_passwordless_auth(struct active_request_slot *slot)
+{
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+#define HTTP_AUTH_PASSWORDLESS (CURLAUTH_GSSNEGOTIATE)
+ curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH,
+ CURLAUTH_ANY ~HTTP_AUTH_PASSWORDLESS);
+#endif
+}
+
+
/* http_request() targets */
#define HTTP_REQUEST_STRBUF 0
#define HTTP_REQUEST_FILE 1
@@ -1035,6 +1047,9 @@ static int http_request(const char *url,
curl_easy_setopt(slot-curl, CURLOPT_HTTPHEADER, headers);
curl_easy_setopt(slot-curl, CURLOPT_ENCODING, gzip);
+ if (!http_passwordless_auth)
+ disable_passwordless_auth(slot);
+
ret = run_one_slot(slot, results);
if (options options-content_type) {
@@ -1139,6 +1154,7 @@ static int http_request_reauth(const char *url,
}
credential_fill(http_auth);
+ http_passwordless_auth = 0;
return http_request(url, result, target, options);
}
diff --git a/http.h b/http.h
index 473179b..71943d3 100644
--- a/http.h
+++ b/http.h
@@ -98,6 +98,8 @@ extern int handle_curl_result(struct slot_results *results);
int run_one_slot(struct active_request_slot *slot,
struct slot_results *results);
+void disable_passwordless_auth(struct active_request_slot *slot);
+
#ifdef USE_CURL_MULTI
extern void fill_active_slots(void);
extern void add_fill_function(void *data, int (*fill)(void *));
@@ -112,6 +114,7 @@ extern int active_requests;
extern int http_is_verbose;
extern size_t http_post_buffer;
extern struct credential http_auth;
+extern int http_passwordless_auth;
extern char curl_errorstr[CURL_ERROR_SIZE];
diff --git a/remote-curl.c b/remote-curl.c
index dd63bc2..4ca5447 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -467,6 +467,9 @@ static int probe_rpc(struct rpc_state *rpc, struct
slot_results *results)
curl_easy_setopt(slot-curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(slot-curl, CURLOPT_FILE, buf);
+ if (!http_passwordless_auth)
+ disable_passwordless_auth(slot);
+
err = run_slot(slot, results);
curl_slist_free_all(headers);
@@ -510,8 +513,10 @@ static int post_rpc(struct rpc_state *rpc)
do {
err = probe_rpc(rpc, results);
- if (err == HTTP_REAUTH)
+ if (err == HTTP_REAUTH) {
credential_fill(http_auth);
+ http_passwordless_auth = 0;
+ }
} while (err == HTTP_REAUTH);
if (err != HTTP_OK)
return -1;
@@ -533,6 +538,9 @@ retry:
curl_easy_setopt(slot-curl, CURLOPT_URL, rpc-service_url);
curl_easy_setopt(slot-curl, CURLOPT_ENCODING, gzip);
+ if (!http_passwordless_auth)
+ disable_passwordless_auth(slot);
+
if (large_request) {
/* The request body is large and the size cannot be predicted.
* We must use chunked encoding to send it.
@@ -617,6 +625,7 @@ retry:
err = run_slot(slot, NULL);
if (err == HTTP_REAUTH !large_request
Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails
I have tried both patches. Neither succeeds here. I patched git version 2.2.1
but I don’t think that affects this.
Before I flood the list with debug runs, I wanted to make sure I was testing
with an appropriate configuration:
Location /git
SSLOptions +StdenvVars
Options +ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
# By default, allow access to anyone.
Order allow,deny
Allow from All
# Enable Kerberos authentication using mod_auth_kerb.
AuthType Kerberos
AuthName “us.example.org
KrbAuthRealms us.example.org
# I have tried both with and without the following line:
KrbServiceName HTTP/us.example.org
Krb5Keytab /usr/local/etc/apache22/repo-test.keytab
KrbMethodNegotiate on
KrbSaveCredentials on
KrbVerifyKDC on
KrbServiceName Any
# I have tried with and without this line:
KrbMethodk5Passwd on
Require valid-user
/Location
With a valid ticket, the above works for a git clone.
—
Dan Langille
Infrastructure Operations
Talos Group
Sourcefire, Inc.
On Jan 1, 2015, at 2:56 PM, brian m. carlson sand...@crustytoothpaste.net
wrote:
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.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
http.c| 16
http.h| 3 +++
remote-curl.c | 11 ++-
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/http.c b/http.c
index 040f362..815194d 100644
--- a/http.c
+++ b/http.c
@@ -62,6 +62,8 @@ static const char *user_agent;
static struct credential cert_auth = CREDENTIAL_INIT;
static int ssl_cert_password_required;
+/* Should we allow non-password-based authentication (e.g. GSSAPI)? */
+int http_passwordless_auth = 1;
static struct curl_slist *pragma_header;
static struct curl_slist *no_pragma_header;
@@ -986,6 +988,16 @@ static void extract_content_type(struct strbuf *raw,
struct strbuf *type,
strbuf_addstr(charset, ISO-8859-1);
}
+void disable_passwordless_auth(struct active_request_slot *slot)
+{
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+#define HTTP_AUTH_PASSWORDLESS (CURLAUTH_GSSNEGOTIATE)
+ curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH,
+ CURLAUTH_ANY ~HTTP_AUTH_PASSWORDLESS);
+#endif
+}
+
+
/* http_request() targets */
#define HTTP_REQUEST_STRBUF 0
#define HTTP_REQUEST_FILE 1
@@ -1035,6 +1047,9 @@ static int http_request(const char *url,
curl_easy_setopt(slot-curl, CURLOPT_HTTPHEADER, headers);
curl_easy_setopt(slot-curl, CURLOPT_ENCODING, gzip);
+ if (!http_passwordless_auth)
+ disable_passwordless_auth(slot);
+
ret = run_one_slot(slot, results);
if (options options-content_type) {
@@ -1139,6 +1154,7 @@ static int http_request_reauth(const char *url,
}
credential_fill(http_auth);
+ http_passwordless_auth = 0;
return http_request(url, result, target, options);
}
diff --git a/http.h b/http.h
index 473179b..71943d3 100644
--- a/http.h
+++ b/http.h
@@ -98,6 +98,8 @@ extern int handle_curl_result(struct slot_results *results);
int run_one_slot(struct active_request_slot *slot,
struct slot_results *results);
+void disable_passwordless_auth(struct active_request_slot *slot);
+
#ifdef USE_CURL_MULTI
extern void fill_active_slots(void);
extern void add_fill_function(void *data, int (*fill)(void *));
@@ -112,6 +114,7 @@ extern int active_requests;
extern int http_is_verbose;
extern size_t http_post_buffer;
extern struct credential http_auth;
+extern int http_passwordless_auth;
extern char curl_errorstr[CURL_ERROR_SIZE];
diff --git a/remote-curl.c b/remote-curl.c
index dd63bc2..4ca5447 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -467,6 +467,9 @@ static int probe_rpc(struct rpc_state *rpc, struct
slot_results *results)
curl_easy_setopt(slot-curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(slot-curl, CURLOPT_FILE, buf);
+ if (!http_passwordless_auth)
+ disable_passwordless_auth(slot);
+
err = run_slot(slot, results);
curl_slist_free_all(headers);
@@ -510,8 +513,10 @@ static int post_rpc(struct rpc_state *rpc)
do
Re: git-http-backend auth via Kerberos
On Dec 18, 2014, at 5:54 PM, brian m. carlson sand...@crustytoothpaste.net 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: 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 requirevalid-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.
Re: git-http-backend auth via Kerberos
On Dec 19, 2014, at 10:07 AM, Dan Langille (dalangil) dalan...@cisco.com 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) dalan...@cisco.com 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 3:16 PM, brian m. carlson sand...@crustytoothpaste.net
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:
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
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
git-http-backend auth via Kerberos
I am trying to get http://git-scm.com/docs/git-http-backend to auth via
Kerberos.
I have success when a Kerberos ticket is present.
I am trying to get git to authenticate with Kerberos when a ticket is not
present.
Here is what succeeds with a ticket:
Location /git
SSLOptions +StdenvVars
Options +ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
# By default, allow access to anyone.
Order allow,deny
Allow from All
# Enable Kerberos authentication using mod_auth_kerb.
AuthType Kerberos
AuthName “us.example.com
KrbAuthRealm us.example.com
Krb5KeyTab /usr/local/etc/apache22/repo-test.keytab
KrbMethodNegotiate on
KrbSaveCredentials on
KrbVerifyKDC on
KrbServiceName Any
Require valid-user
/Location
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/'
Of note, I see this in the Apache logs:
Thu Dec 18 16:43:35 2014] [debug] src/mod_auth_kerb.c(1749): [client
10.7.69.10] kerb_authenticate_user entered with user (NULL) and auth_type
Kerberos
Ideas? Suggestions? Hints? Thanks.
—
Dan Langille
Infrastructure Operations
Talos Group
Sourcefire, Inc.
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
