{"thread":{"id":"37185","subject":"Git + mod_auth_kerb","startedAt":"2014-07-21T21:06:50Z","lastAt":"2014-07-26T20:57:16Z","messageCount":7,"participants":["Jean-Francois Bouchard","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"246481","messageId":"CAPYmS35cgcEOfKvT17tULYyxL5GgXBavkD6anhV6yJtdoXVE9Q@mail.gmail.com","threadId":"37185","inReplyTo":null,"subject":"Git + mod_auth_kerb","fromName":"Jean-Francois Bouchard","fromEmail":"jfbouchard@accedian.com","sentAt":"2014-07-21T21:06:50Z","receivedAt":"2014-07-21T21:06:50Z","isPatch":false,"sender":{"key":"jfbouchard@accedian.com","avatar":null},"body":"Hello,\n\nWe are currently working on a single sign on setup for our git install. We are\nusing git 2.0.2 (ubuntu) plus apache/2.2.22 mod_auth_kerb on the\nserver side. Here some scenario we are trying to accomplish :\n\n-Without Kerberos ticket stored.\nGit ask for username/password.\nResult = Authentication failed\n\n-Kerberos ticket in store and BAD password :\nGit ask for username/password.\nResult = Authentication failed\n\n-Kerberos ticket in Store entering good password :\nGit ask for username/password.\nResult = Authentication failed on some host, other works\n\n-Kerberos ticket in Store and embedding the username in the URI (aka\nhttps://username@repo)\nGit don't ask for anything or ask for password\nResult = Works on some host, other request the password. (Will fail if\nthe kerberos ticket not in store)\n\nThis is a very strange behaviour. It seems to be cause by the way\nlibcurl and git interact and the way the authentication goes\n(Negociate first, then basic auth). I have tried to use the helper to\nstore invalid authentication information. With not much success.\n\n\n\nAny idea ?\n\nThanks,\n\nJF\n\n-- \n\n\nAvis de confidentialité\n\nLes informations contenues dans le présent message et dans toute pièce qui \nlui est jointe sont confidentielles et peuvent être protégées par le secret \nprofessionnel. Ces informations sont à l’usage exclusif de son ou de ses \ndestinataires. Si vous recevez ce message par erreur, veuillez s’il vous \nplait communiquer immédiatement avec l’expéditeur et en détruire tout \nexemplaire. De plus, il vous est strictement interdit de le divulguer, de \nle distribuer ou de le reproduire sans l’autorisation de l’expéditeur. \nMerci.\n\nConfidentiality notice\n\nThis e-mail message and any attachment hereto contain confidential \ninformation which may be privileged and which is intended for the exclusive \nuse of its addressee(s). If you receive this message in error, please \ninform sender immediately and destroy any copy thereof. Furthermore, any \ndisclosure, distribution or copying of this message and/or any attachment \nhereto without the consent of the sender is strictly prohibited. Thank you.\n"},{"id":"246489","messageId":"20140721231721.GB5616@vauxhall.crustytoothpaste.net","threadId":"37185","inReplyTo":"CAPYmS35cgcEOfKvT17tULYyxL5GgXBavkD6anhV6yJtdoXVE9Q@mail.gmail.com","subject":"Re: Git + mod_auth_kerb","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-07-21T23:17:21Z","receivedAt":"2014-07-21T23:17:21Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Jul 21, 2014 at 05:06:50PM -0400, Jean-Francois Bouchard wrote:\n> Hello,\n> \n> We are currently working on a single sign on setup for our git install. We are\n> using git 2.0.2 (ubuntu) plus apache/2.2.22 mod_auth_kerb on the\n> server side. Here some scenario we are trying to accomplish :\n> \n> -Without Kerberos ticket stored.\n> Git ask for username/password.\n> Result = Authentication failed\n> \n> -Kerberos ticket in store and BAD password :\n> Git ask for username/password.\n> Result = Authentication failed\n> \n> -Kerberos ticket in Store entering good password :\n> Git ask for username/password.\n> Result = Authentication failed on some host, other works\n> \n> -Kerberos ticket in Store and embedding the username in the URI (aka\n> https://username@repo)\n> Git don't ask for anything or ask for password\n> Result = Works on some host, other request the password. (Will fail if\n> the kerberos ticket not in store)\n\nSo git uses libcurl with CURLAUTH_ANY.  In order for authentication to\nwork with libcurl, you have to supply a username.  If you specify it in\nthe URL, the libcurl realizes that it can use Kerberos, and goes on its\nmerry way.\n\nIf you don't specify the username in the URL, git notices that\nauthentication has failed, and asks the credential store for a username\nand password.  git does not know that a password is not needed, so the\ncredential subsystem prompts for one anyway.\n\nI have mod_auth_kerb set up against Apache 2.4.9 at the moment, although\nI've used 2.2 before.  I always use a username in the URL, and if I get\nprompted for the password, I just Ctrl-C out and run kinit before\npushing again.\n\nI don't have mod_auth_kerb set up to fall back to basic auth, but if you\ndo, using a username and password should work properly.  You can use\nset the environment variable GIT_CURL_VERBOSE to 1 to see more\ninformation about what's actually going over the wire.\n\n> This is a very strange behaviour. It seems to be cause by the way\n> libcurl and git interact and the way the authentication goes\n> (Negociate first, then basic auth). I have tried to use the helper to\n> store invalid authentication information. With not much success.\n\nlibcurl will always prefer something (anything) over basic auth, since\nbasic auth is completely insecure unless you're using HTTPS.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"246504","messageId":"CAPYmS36r2fTeY4iB3k7VpgE7brAGxa+wt9HzfXtMStbMW4_Xvg@mail.gmail.com","threadId":"37185","inReplyTo":"20140721231721.GB5616@vauxhall.crustytoothpaste.net","subject":"Re: Git + mod_auth_kerb","fromName":"Jean-Francois Bouchard","fromEmail":"jfbouchard@accedian.com","sentAt":"2014-07-22T16:41:19Z","receivedAt":"2014-07-22T16:41:19Z","isPatch":false,"sender":{"key":"jfbouchard@accedian.com","avatar":null},"body":"Hello,\n\nThanks for this info. This make a lot of sense system wise. For a user\npoint of view, it is a nightmare. Also, this break a lot of tools that\nare waiting username/password authentication via HTTPS. (I name\nEclipse).\n\nAlso, I m not able to reproduce the kerberos login on Ubuntu 14.04. I\nm asked to enter password even if a kerberos ticket is present and\nthis even when I've embedded the username in the URI.\n\nIs there a better way to integrate Kerberos via HTTPS for git ?\n\nThanks,\nJF\n\nOn Mon, Jul 21, 2014 at 7:17 PM, brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n> On Mon, Jul 21, 2014 at 05:06:50PM -0400, Jean-Francois Bouchard wrote:\n>> Hello,\n>>\n>> We are currently working on a single sign on setup for our git install. We are\n>> using git 2.0.2 (ubuntu) plus apache/2.2.22 mod_auth_kerb on the\n>> server side. Here some scenario we are trying to accomplish :\n>>\n>> -Without Kerberos ticket stored.\n>> Git ask for username/password.\n>> Result = Authentication failed\n>>\n>> -Kerberos ticket in store and BAD password :\n>> Git ask for username/password.\n>> Result = Authentication failed\n>>\n>> -Kerberos ticket in Store entering good password :\n>> Git ask for username/password.\n>> Result = Authentication failed on some host, other works\n>>\n>> -Kerberos ticket in Store and embedding the username in the URI (aka\n>> https://username@repo)\n>> Git don't ask for anything or ask for password\n>> Result = Works on some host, other request the password. (Will fail if\n>> the kerberos ticket not in store)\n>\n> So git uses libcurl with CURLAUTH_ANY.  In order for authentication to\n> work with libcurl, you have to supply a username.  If you specify it in\n> the URL, the libcurl realizes that it can use Kerberos, and goes on its\n> merry way.\n>\n> If you don't specify the username in the URL, git notices that\n> authentication has failed, and asks the credential store for a username\n> and password.  git does not know that a password is not needed, so the\n> credential subsystem prompts for one anyway.\n>\n> I have mod_auth_kerb set up against Apache 2.4.9 at the moment, although\n> I've used 2.2 before.  I always use a username in the URL, and if I get\n> prompted for the password, I just Ctrl-C out and run kinit before\n> pushing again.\n>\n> I don't have mod_auth_kerb set up to fall back to basic auth, but if you\n> do, using a username and password should work properly.  You can use\n> set the environment variable GIT_CURL_VERBOSE to 1 to see more\n> information about what's actually going over the wire.\n>\n>> This is a very strange behaviour. It seems to be cause by the way\n>> libcurl and git interact and the way the authentication goes\n>> (Negociate first, then basic auth). I have tried to use the helper to\n>> store invalid authentication information. With not much success.\n>\n> libcurl will always prefer something (anything) over basic auth, since\n> basic auth is completely insecure unless you're using HTTPS.\n>\n> --\n> brian m. carlson / brian with sandals: Houston, Texas, US\n> +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\n> OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n\n-- \n\n\nAvis de confidentialité\n\nLes informations contenues dans le présent message et dans toute pièce qui \nlui est jointe sont confidentielles et peuvent être protégées par le secret \nprofessionnel. Ces informations sont à l’usage exclusif de son ou de ses \ndestinataires. Si vous recevez ce message par erreur, veuillez s’il vous \nplait communiquer immédiatement avec l’expéditeur et en détruire tout \nexemplaire. De plus, il vous est strictement interdit de le divulguer, de \nle distribuer ou de le reproduire sans l’autorisation de l’expéditeur. \nMerci.\n\nConfidentiality notice\n\nThis e-mail message and any attachment hereto contain confidential \ninformation which may be privileged and which is intended for the exclusive \nuse of its addressee(s). If you receive this message in error, please \ninform sender immediately and destroy any copy thereof. Furthermore, any \ndisclosure, distribution or copying of this message and/or any attachment \nhereto without the consent of the sender is strictly prohibited. Thank you.\n"},{"id":"246506","messageId":"xmqqfvhtgwgp.fsf@gitster.dls.corp.google.com","threadId":"37185","inReplyTo":"20140721231721.GB5616@vauxhall.crustytoothpaste.net","subject":"Re: Git + mod_auth_kerb","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-07-22T17:00:22Z","receivedAt":"2014-07-22T17:00:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> So git uses libcurl with CURLAUTH_ANY.  In order for authentication to\n> work with libcurl, you have to supply a username.  If you specify it in\n> the URL, the libcurl realizes that it can use Kerberos, and goes on its\n> merry way.\n>\n> If you don't specify the username in the URL, git notices that\n> authentication has failed, and asks the credential store for a username\n> and password.  git does not know that a password is not needed, so the\n> credential subsystem prompts for one anyway.\n\nHmmm, does this hint that we might want to be able to tell the\ncredential subsystem that it is sufficient to have name without\npassword, or allow the credential subsystem to say \"I am giving you\nsufficient information\" when it returns only username without\npassword?\n"},{"id":"246534","messageId":"20140722233243.GE5616@vauxhall.crustytoothpaste.net","threadId":"37185","inReplyTo":"xmqqfvhtgwgp.fsf@gitster.dls.corp.google.com","subject":"Re: Git + mod_auth_kerb","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-07-22T23:32:44Z","receivedAt":"2014-07-22T23:32:44Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Jul 22, 2014 at 10:00:22AM -0700, Junio C Hamano wrote:\n> \"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n> \n> > So git uses libcurl with CURLAUTH_ANY.  In order for authentication to\n> > work with libcurl, you have to supply a username.  If you specify it in\n> > the URL, the libcurl realizes that it can use Kerberos, and goes on its\n> > merry way.\n> >\n> > If you don't specify the username in the URL, git notices that\n> > authentication has failed, and asks the credential store for a username\n> > and password.  git does not know that a password is not needed, so the\n> > credential subsystem prompts for one anyway.\n> \n> Hmmm, does this hint that we might want to be able to tell the\n> credential subsystem that it is sufficient to have name without\n> password, or allow the credential subsystem to say \"I am giving you\n> sufficient information\" when it returns only username without\n> password?\n\nPossibly.  In the --negotiate documentation of the curl man page, it\nsays:\n\n  When using this option, you must also provide a fake -u, --user option\n  to activate the authentication code properly. Sending a '-u :' is\n  enough as the user name and password from the -u option aren't\n  actually used.\n\nThat implies to me that setting an empty value for CURLOPT_USERNAME in\ngit might be sufficient to solve the problem.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"246538","messageId":"20140723015955.GF5616@vauxhall.crustytoothpaste.net","threadId":"37185","inReplyTo":"CAPYmS36r2fTeY4iB3k7VpgE7brAGxa+wt9HzfXtMStbMW4_Xvg@mail.gmail.com","subject":"Re: Git + mod_auth_kerb","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-07-23T01:59:56Z","receivedAt":"2014-07-23T01:59:56Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Jul 22, 2014 at 12:41:19PM -0400, Jean-Francois Bouchard wrote:\n> Thanks for this info. This make a lot of sense system wise. For a user\n> point of view, it is a nightmare. Also, this break a lot of tools that\n> are waiting username/password authentication via HTTPS. (I name\n> Eclipse).\n\nWhat you may want to do is have each user adjust their .gitconfig to do\nsomething like:\n\n  [url \"https://bmc@git.crustytoothpaste.net/\"]\n    insteadOf = https://git.crustytoothpaste.net/\n\nThat way, everyone can continue to use the same URLs, but have git fix\nthem up per-user.\n\nHopefully I'll get some time this week to see if making HTTPS requests\nprovide an empty username by default will work.\n\n> Also, I m not able to reproduce the kerberos login on Ubuntu 14.04. I\n> m asked to enter password even if a kerberos ticket is present and\n> this even when I've embedded the username in the URI.\n\nThis sounds like an issue with Kerberos and curl on Ubuntu 14.04.  I'm\nusing Debian unstable (from which Ubuntu pulls changes), and at no point\nhave I had this problem.  Can you send us the output of the push with\nthe environment GIT_CURL_VERBOSE set to 1 on a system where it works and\none where it doesn't?\n\n> Is there a better way to integrate Kerberos via HTTPS for git ?\n\nI don't know of any better way.  It does work for me, although I'm just\none person.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"246760","messageId":"20140726205716.GB155979@vauxhall.crustytoothpaste.net","threadId":"37185","inReplyTo":"xmqqfvhtgwgp.fsf@gitster.dls.corp.google.com","subject":"Re: Git + mod_auth_kerb","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-07-26T20:57:16Z","receivedAt":"2014-07-26T20:57:16Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Jul 22, 2014 at 10:00:22AM -0700, Junio C Hamano wrote:\n> \"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n> \n> > So git uses libcurl with CURLAUTH_ANY.  In order for authentication to\n> > work with libcurl, you have to supply a username.  If you specify it in\n> > the URL, the libcurl realizes that it can use Kerberos, and goes on its\n> > merry way.\n> >\n> > If you don't specify the username in the URL, git notices that\n> > authentication has failed, and asks the credential store for a username\n> > and password.  git does not know that a password is not needed, so the\n> > credential subsystem prompts for one anyway.\n> \n> Hmmm, does this hint that we might want to be able to tell the\n> credential subsystem that it is sufficient to have name without\n> password, or allow the credential subsystem to say \"I am giving you\n> sufficient information\" when it returns only username without\n> password?\n\nI just did some testing here, and on my configuration (mod_auth_kerb\nwithout Basic authentication fallback), hitting enter at both the\nusername and password prompts results in a successful connection with\nstock git.  This makes sense, because with GSSAPI authentication, your\nticket is tied to your username, so no explicit username is needed.\n\nIf I turn on KrbMethodK5Passwd and try to push without credentials, I\ncan confirm that git refuses, even if the correct password is set.  It\nlooks like libcurl really doesn't want to use Basic authentication if\nthere's a \"better\" choice.\n\nJean-Francois, do you have KrbMethodK5Passwd set to on (the default)?\nIf so, you might try turning it off and forcing Kerberos authentication\nall the time.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"}]}