{"thread":{"id":"33352","subject":"git https transport and wrong password","startedAt":"2013-04-02T15:54:40Z","lastAt":"2013-04-03T16:15:36Z","messageCount":9,"participants":["Mikko Rapeli","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"212891","messageId":"20130402155440.GT30514@lakka.kapsi.fi","threadId":"33352","inReplyTo":null,"subject":"git https transport and wrong password","fromName":"Mikko Rapeli","fromEmail":"mikko.rapeli@iki.fi","sentAt":"2013-04-02T15:54:40Z","receivedAt":"2013-04-02T15:54:40Z","isPatch":false,"sender":{"key":"mikko.rapeli@iki.fi","avatar":"https://avatars.githubusercontent.com/u/2036278?v=4"},"body":"Hi,\n\nI have a problem with git (1.7.9 and 1.8.2.357.gcc3e4eb) and https transport\nto gerrit server (2.5.1-3-g719dfc7). I'm producing the problem on Cygwin but my\ncolleagues have same issue on Linux as well.\n\nGerrit server is matching corporate policies with single sign on, so after\nthree failed login attempts the account gets locked until a password reset.\n\nGit amplifies this problem by asking for users password only once, and if\nuser made a typo git is still re-using the wrong password enough times to\nget an account immediately locked.\n\nI have client side logs with GIT_CURL_VERBOSE=1 but from intranet so can't\npublish them directly. Here's roughly what the log shows:\n\n---------------------------------------------------------------\n\n$ GIT_CURL_VERBOSE=1 git fetch\n...\n> GET /gerrit/.../info/refs?service=git-upload-pack HTTP/1.1\n...\n< HTTP/1.1 401 Authorization Required\n...\n\n---------- I guess git prompts for password here. --------------\n\n* Issue another request to this URL: 'https://..info/refs?service=git-upload-pack'\n...\n* Re-using existing connection! ...\n...\n* Server auth using Basic with user '...'\n> GET /gerrit/.../info/refs?service=git-upload-pack HTTP/1.1\nAuthorization: Basic ...\n...\n< HTTP/1.1 401 Authorization Required\n< Date: ...\n* Authentication problem. Ignoring this.\n...\n* The requested URL returned error: 401\n* Closing connection 0\n...\n* About to connect() to ...\n...\n* Connected to ...\n...\n* STATE: PROTOCONNECT => DO handle...\n* Server auth using Basic with user '...'\n> GET /gerrit/.../info/refs?service=git-upload-pack HTTP/1.1\nAuthorization: Basic ...\n...\n* STATE: DO => DO_DONE handle...\n* STATE: DO_DONE => WAITPERFORM handle...\n* STATE: WAITPERFORM => PERFORM handle...\n...\n< HTTP/1.1 302 Found\n...\n< Location: ...funnylongurl\n...\n* Ignoring the response-body\n* Connection #1 to host ... left intact\n* Issue another request to this URL: '...funnylongurl'\n...\n* Server auth using Basic with user '...'\n> GET ...funnylongurl\nAuthorization: Basic ...\n...\n* The requested URL returned error: 500 Internal Server Error\n* Closing connection 1\n...\n* About to connect()...\n...\n* Server auth using Basic with user '...'\n> GET /gerrit/.../info/refs HTTP/1.1\nAuthorization: Basic ...\n...\n< HTTP/1.1 302 Found\n< Date...\n< Set-Cookie...\n< Cache-Control: no-store\n< Location: ...funnylongurl\n...\n* Re-using existing connection! (#2)...\n> GET ...funnylongurl\n...\n* The requested URL returned error: 500 Internal Server Error\n* Closing connection 2\n...\nerror: The requested URL returned error: 500 Internal Server Error while accessing ...\nfatal: HTTP request failed\n\n---------------------------------------------------------------\n\nAny idea what could be wrong here? Is git client really retrying with the\nbad password?\n\nRegards,\n\n-Mikko\n"},{"id":"212896","messageId":"20130402162308.GU30514@lakka.kapsi.fi","threadId":"33352","inReplyTo":"20130402155440.GT30514@lakka.kapsi.fi","subject":"Re: git https transport and wrong password","fromName":"Mikko Rapeli","fromEmail":"mikko.rapeli@iki.fi","sentAt":"2013-04-02T16:23:08Z","receivedAt":"2013-04-02T16:23:08Z","isPatch":false,"sender":{"key":"mikko.rapeli@iki.fi","avatar":"https://avatars.githubusercontent.com/u/2036278?v=4"},"body":"On Tue, Apr 02, 2013 at 06:54:40PM +0300, Mikko Rapeli wrote:\n> I have client side logs with GIT_CURL_VERBOSE=1 but from intranet so can't\n> publish them directly. Here's roughly what the log shows:\n\nMaybe this is simpler summary:\n\n$ grep \"HTTP\\/1.1\" log.txt\n> GET ...info/refs?service=git-upload-pack\n< HTTP/1.1 401 Authorization required\n\npassword prompt here, and ctrl-c does not work in Cygwin, sigh.\n\n> GET ...info/refs?service=git-upload-pack\n< HTTP/1.1 401 Authorization required\n> GET ...info/refs?service=git-upload-pack\n< HTTP/1.1 302 Found\n\naccount locked I presume\n\n> GET longredirecturl\n> GET ...info/refs\n> HTTP/1.1 302 Found\n> GET longredirecturl\n\nI was not able reproduce this issue using curl directly to get the info/refs\npage.\n\n-Mikko\n"},{"id":"212965","messageId":"20130402192845.GC17784@sigill.intra.peff.net","threadId":"33352","inReplyTo":"20130402155440.GT30514@lakka.kapsi.fi","subject":"Re: git https transport and wrong password","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-02T19:28:45Z","receivedAt":"2013-04-02T19:28:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 02, 2013 at 06:54:40PM +0300, Mikko Rapeli wrote:\n\n> I have a problem with git (1.7.9 and 1.8.2.357.gcc3e4eb) and https transport\n> to gerrit server (2.5.1-3-g719dfc7). I'm producing the problem on Cygwin but my\n> colleagues have same issue on Linux as well.\n> \n> Gerrit server is matching corporate policies with single sign on, so after\n> three failed login attempts the account gets locked until a password reset.\n> \n> Git amplifies this problem by asking for users password only once, and if\n> user made a typo git is still re-using the wrong password enough times to\n> get an account immediately locked.\n\nHmm. The sequence should be:\n\n  - request, get 401\n  - prompt user for password\n  - retry request with password\n  - if 401, die\n\nIOW, we should make only a single request with the credential, and\nimmediately die afterwards. We do hit once to get the initial 401, but\nwe do not even provide a username, so unless the corporate policy is\nlocking out based on IP, it should not matter (and if it is, that shows\na fundamental misunderstanding about how a 401 is supposed to work).\n\nBut from your log, I see:\n\n> ---------------------------------------------------------------\n> \n> $ GIT_CURL_VERBOSE=1 git fetch\n> ...\n> > GET /gerrit/.../info/refs?service=git-upload-pack HTTP/1.1\n> ...\n> < HTTP/1.1 401 Authorization Required\n> ...\n\nHere's our first 401. OK.\n\n> ---------- I guess git prompts for password here. --------------\n\nMaybe...see below.\n\n> * Server auth using Basic with user '...'\n> > GET /gerrit/.../info/refs?service=git-upload-pack HTTP/1.1\n> Authorization: Basic ...\n> ...\n> < HTTP/1.1 401 Authorization Required\n> < Date: ...\n> * Authentication problem. Ignoring this.\n> ...\n> * The requested URL returned error: 401\n\nWe get another 401. Now git should die. But it doesn't:\n\n> * STATE: PROTOCONNECT => DO handle...\n> * Server auth using Basic with user '...'\n> > GET /gerrit/.../info/refs?service=git-upload-pack HTTP/1.1\n> Authorization: Basic ...\n\nIt makes another request instead.\n\nWeirdly, this does not result in a 401:\n\n> * STATE: DO => DO_DONE handle...\n> * STATE: DO_DONE => WAITPERFORM handle...\n> * STATE: WAITPERFORM => PERFORM handle...\n> ...\n> < HTTP/1.1 302 Found\n> ...\n> < Location: ...funnylongurl\n> ...\n> * Ignoring the response-body\n> * Connection #1 to host ... left intact\n> * Issue another request to this URL: '...funnylongurl'\n> ...\n> * Server auth using Basic with user '...'\n> > GET ...funnylongurl\n> Authorization: Basic ...\n> ...\n> * The requested URL returned error: 500 Internal Server Error\n> * Closing connection 1\n\nWe get redirected somewhere where we provide the (presumably wrong)\ncredential again. I do not think that is git's fault; the server asked\nus to make the extra request. Is that part of the lockout procedure? If\nit is not, it seems odd that the server would issue a redirect for a\nbogus auth (shouldn't it just keep giving us 401?).\n\nI do not know what is going on with the redirection there, but I have a\nhunch on the extra auth round-trip.  What does your remote URL look\nlike? Does it have your username (e.g., https://user@host/project.git)?\n\nI have noticed that if curl sees such a URL, it attempts to do a\npassword-less authentication itself, before even handing control back to\ngit. So my above sequence would become:\n\n  1. git feeds URL to curl, who makes request\n  2. we get a 401\n  3. curl says \"Oh, I have a username; let me try that\" and re-requests\n  4. we get another 401, because we need a password\n  5. curl says \"that didn't work\" and hands control back to git\n  6. git requests a password from the user and gives it to curl\n  7. curl retries with the password, but it's wrong, so that results in\n     a 401, too\n\nAt the end of it, we've now made _two_ failed requests for user X,\nrather than one. I don't know if there's a way to tell curl not to try\nthe extra user-only round-trip. But you can strip the username out of\nyour URL to avoid it.\n\n-Peff\n"},{"id":"212972","messageId":"20130402194751.GV30514@lakka.kapsi.fi","threadId":"33352","inReplyTo":"20130402192845.GC17784@sigill.intra.peff.net","subject":"Re: git https transport and wrong password","fromName":"Mikko Rapeli","fromEmail":"mikko.rapeli@iki.fi","sentAt":"2013-04-02T19:47:51Z","receivedAt":"2013-04-02T19:47:51Z","isPatch":false,"sender":{"key":"mikko.rapeli@iki.fi","avatar":"https://avatars.githubusercontent.com/u/2036278?v=4"},"body":"On Tue, Apr 02, 2013 at 03:28:45PM -0400, Jeff King wrote:\n> We get redirected somewhere where we provide the (presumably wrong)\n> credential again. I do not think that is git's fault; the server asked\n> us to make the extra request. Is that part of the lockout procedure? If\n> it is not, it seems odd that the server would issue a redirect for a\n> bogus auth (shouldn't it just keep giving us 401?).\n\nI think it is supposed to be a catch all failure mode without any\nauthentication but is just wrong/buggy. I'll try to debug these by\nissuing curl commands step by step.\n\n> I do not know what is going on with the redirection there, but I have a\n> hunch on the extra auth round-trip.  What does your remote URL look\n> like? Does it have your username (e.g., https://user@host/project.git)?\n\nYes, that's the giturl format I have.\n\n> I have noticed that if curl sees such a URL, it attempts to do a\n> password-less authentication itself, before even handing control back to\n> git. So my above sequence would become:\n> \n>   1. git feeds URL to curl, who makes request\n>   2. we get a 401\n>   3. curl says \"Oh, I have a username; let me try that\" and re-requests\n>   4. we get another 401, because we need a password\n>   5. curl says \"that didn't work\" and hands control back to git\n>   6. git requests a password from the user and gives it to curl\n>   7. curl retries with the password, but it's wrong, so that results in\n>      a 401, too\n> \n> At the end of it, we've now made _two_ failed requests for user X,\n> rather than one. I don't know if there's a way to tell curl not to try\n> the extra user-only round-trip. But you can strip the username out of\n> your URL to avoid it.\n\nIt did seem like there was just one GET and 401 return before password\nwas promptet. I'll tripple check that.\n\nPlayed around with command line curl a bit and at least it did the right\nthing with a URL without username -- failed with 401 after single try --\nand with URL without username but username provided -u 'username' which\nsucceeded or failed on single try based on password.\n\nDon't know anything about curl but maybe git could parse the url for a\nusername and prompt for the password before the first 401 failure roundtrip\nthat's now in place. I guess most of this logic is in http.c.\n\n-Mikko\n"},{"id":"212981","messageId":"20130402200551.GA535@sigill.intra.peff.net","threadId":"33352","inReplyTo":"20130402194751.GV30514@lakka.kapsi.fi","subject":"Re: git https transport and wrong password","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-02T20:05:51Z","receivedAt":"2013-04-02T20:05:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 02, 2013 at 10:47:51PM +0300, Mikko Rapeli wrote:\n\n> Don't know anything about curl but maybe git could parse the url for a\n> username and prompt for the password before the first 401 failure roundtrip\n> that's now in place. I guess most of this logic is in http.c.\n\nWe used to do that but stopped, as curl might also be able to retrieve\nthe password from .netrc; the extra prompt was an annoyance to users\nin this situation.\n\nNow that we have the credential subsystem, I would recommend dropping\nusernames from all git-over-http URLs, and either:\n\n  1. Using a credential helper that supports secure long-term storage\n     (osxkeychain, wincred, etc).\n\n  2. Specifying the username to the credential subsystem explicitly, by\n     putting something like:\n\n       [credential \"https://yourhost/\"]\n              username = yourusername\n\n     in your git config.\n\nObviously (1) is nicer, but you may have corporate policies against\nstoring credentials. Or you may have a complicated single sign-on\nprocedure, where the password changes. In that case, I would still say\nit is worth writing a custom helper script that can feed the temporary\ncredential to git.\n\n-Peff\n"},{"id":"212985","messageId":"20130402202054.GX30514@lakka.kapsi.fi","threadId":"33352","inReplyTo":"20130402200551.GA535@sigill.intra.peff.net","subject":"Re: git https transport and wrong password","fromName":"Mikko Rapeli","fromEmail":"mikko.rapeli@iki.fi","sentAt":"2013-04-02T20:20:54Z","receivedAt":"2013-04-02T20:20:54Z","isPatch":false,"sender":{"key":"mikko.rapeli@iki.fi","avatar":"https://avatars.githubusercontent.com/u/2036278?v=4"},"body":"On Tue, Apr 02, 2013 at 04:05:51PM -0400, Jeff King wrote:\n> On Tue, Apr 02, 2013 at 10:47:51PM +0300, Mikko Rapeli wrote:\n> \n> > Don't know anything about curl but maybe git could parse the url for a\n> > username and prompt for the password before the first 401 failure roundtrip\n> > that's now in place. I guess most of this logic is in http.c.\n> \n> We used to do that but stopped, as curl might also be able to retrieve\n> the password from .netrc; the extra prompt was an annoyance to users\n> in this situation.\n\nOk, I think I've seen this before and ended up storing passwords in .netrc.\n\n> Now that we have the credential subsystem, I would recommend dropping\n> usernames from all git-over-http URLs, and either:\n> \n>   1. Using a credential helper that supports secure long-term storage\n>      (osxkeychain, wincred, etc).\n> \n>   2. Specifying the username to the credential subsystem explicitly, by\n>      putting something like:\n> \n>        [credential \"https://yourhost/\"]\n>               username = yourusername\n> \n>      in your git config.\n> \n> Obviously (1) is nicer, but you may have corporate policies against\n> storing credentials. Or you may have a complicated single sign-on\n> procedure, where the password changes. In that case, I would still say\n> it is worth writing a custom helper script that can feed the temporary\n> credential to git.\n\nThanks, I'll have a look at these helpers. Policies we may have but in\npractice I think many just store plaintext passwords in giturls, which\nis obviously the worst case, but it works against accidental typos in\nthe password prompt (though blows up when the mandatory password change\ncomes along).\n\n-Mikko\n"},{"id":"213029","messageId":"20130403094302.GY30514@lakka.kapsi.fi","threadId":"33352","inReplyTo":"20130402202054.GX30514@lakka.kapsi.fi","subject":"Re: git https transport and wrong password","fromName":"Mikko Rapeli","fromEmail":"mikko.rapeli@iki.fi","sentAt":"2013-04-03T09:43:02Z","receivedAt":"2013-04-03T09:43:02Z","isPatch":false,"sender":{"key":"mikko.rapeli@iki.fi","avatar":"https://avatars.githubusercontent.com/u/2036278?v=4"},"body":"Maybe my git installation was incomplete before when running from ~/bin since\nI was not able to set break points to http_request() and some debug code\nwas not there until I ran git through bin-wrappers in the source tree.\n\nI added some debug prints to http.c functions http_request() and\nhandle_curl_result(), and now I see this chain of events:\n\n http_request_reauth()\n http_request()\n GET ...info/refs?service=git-upload-pack\n HTTP/1.1 401 Authorization Required\n* Ignoring the response-body\n* Issue another request to this URL: '...'\n GET ...info/refs?service=git-upload-pack\n HTTP/1.1 401 Authorization Required\n handle_curl_result: res = 22, http_code = 401, user = ..., pass = (null)\nPassword for '...': (enter valid password)\n GET ...info/refs?service=git-upload-pack\n HTTP/1.1 200 OK\n\nSo, for some reason the first GET request is issued twice and first 401\nis ignored. I'll try to debug run_active_slot() next...\n\n-Mikko\n"},{"id":"213033","messageId":"20130403141212.GA10494@sigill.intra.peff.net","threadId":"33352","inReplyTo":"20130403094302.GY30514@lakka.kapsi.fi","subject":"Re: git https transport and wrong password","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-03T14:12:12Z","receivedAt":"2013-04-03T14:12:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[+cc Daniel for curl questions below]\n\nOn Wed, Apr 03, 2013 at 12:43:02PM +0300, Mikko Rapeli wrote:\n\n> Maybe my git installation was incomplete before when running from ~/bin since\n> I was not able to set break points to http_request() and some debug code\n> was not there until I ran git through bin-wrappers in the source tree.\n\nDebugging git-over-http is somewhat difficult because the interesting\nbits happen in sub-processes. You can get much closer to the http calls\nby running the transport helper directly, like:\n\n  gdb --args git-remote-https https://yourhost/\n\nwhich will start by reading commands from stdin (try \"list\" to get it to\nfetch the remote refs).\n\n> I added some debug prints to http.c functions http_request() and\n> handle_curl_result(), and now I see this chain of events:\n> \n>  http_request_reauth()\n>  http_request()\n>  GET ...info/refs?service=git-upload-pack\n>  HTTP/1.1 401 Authorization Required\n> * Ignoring the response-body\n> * Issue another request to this URL: '...'\n>  GET ...info/refs?service=git-upload-pack\n>  HTTP/1.1 401 Authorization Required\n>  handle_curl_result: res = 22, http_code = 401, user = ..., pass = (null)\n> Password for '...': (enter valid password)\n>  GET ...info/refs?service=git-upload-pack\n>  HTTP/1.1 200 OK\n> \n> So, for some reason the first GET request is issued twice and first 401\n> is ignored. I'll try to debug run_active_slot() next...\n\nRight, I think that's curl trying to make use of the username in the\nURL. Try this (I'm using github here as a convenient http servers, but\nyou should be able to replicate with your internal server):\n\n  $ GIT_CURL_VERBOSE=1 git ls-remote https://foo@github.com/requires/auth \\\n      2>&1 >/dev/null | egrep '^>|^< HTTP|^Authorization|requested URL'\n  > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1\n  < HTTP/1.1 401 Authorization Required\n  > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1\n  Authorization: Basic Zm9vOg==\n  < HTTP/1.1 401 Authorization Required\n  * The requested URL returned error: 401\n  Password for 'https://foo@github.com': \n  > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1\n  Authorization: Basic Zm9vOmJhcg==\n  < HTTP/1.1 401 Authorization Required\n  * The requested URL returned error: 401\n\nSo you can see that curl makes _two_ requests internally before it\nreturns the 401. One unadorned, and one with just the username\n(\"Zm9vOg==\", which decodes to \"foo:\") for the auth. Then git prompts for\nthe password, and we retry (and of course I am feeding it a bogus\nusername/password combo, so we get another 401).\n\nI would expect without the username in the URL for it to make only two\nrequests: one to get the first 401, then git collects the credentials,\nthen a follow-up with the credentials. But instead we get:\n\n  $ GIT_CURL_VERBOSE=1 git ls-remote https://github.com/requires/auth \\\n      2>&1 >/dev/null | egrep '^>|^< HTTP|^Authorization|requested URL'\n  > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1\n  * The requested URL returned error: 401 Authorization Required\n  Username for 'https://github.com': foo\n  Password for 'https://foo@github.com': \n  > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1\n  < HTTP/1.1 401 Authorization Required\n  > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1\n  Authorization: Basic Zm9vOmJhcg==\n  < HTTP/1.1 401 Authorization Required\n  * The requested URL returned error: 401\n\nSo we get a 401, as expected, git prompts for the credentials and feeds\nthem directly to curl, but then we still get _two_ requests: we trigger\nanother 401, and only then does curl provide the authorization header to\nthe server.\n\nI'm not sure if that extra auth is intended or not.\n\nIt's also possible that git is screwing up in providing the credentials\nto curl, but I don't think so. We feed them to the curl handle as soon\nas we get them, and there should be only one handle in use here.\n\n-Peff\n"},{"id":"213051","messageId":"20130403161536.GZ30514@lakka.kapsi.fi","threadId":"33352","inReplyTo":"20130403141212.GA10494@sigill.intra.peff.net","subject":"Re: git https transport and wrong password","fromName":"Mikko Rapeli","fromEmail":"mikko.rapeli@iki.fi","sentAt":"2013-04-03T16:15:36Z","receivedAt":"2013-04-03T16:15:36Z","isPatch":false,"sender":{"key":"mikko.rapeli@iki.fi","avatar":"https://avatars.githubusercontent.com/u/2036278?v=4"},"body":"On Wed, Apr 03, 2013 at 10:12:12AM -0400, Jeff King wrote:\n> I would expect without the username in the URL for it to make only two\n> requests: one to get the first 401, then git collects the credentials,\n> then a follow-up with the credentials. But instead we get:\n> \n>   $ GIT_CURL_VERBOSE=1 git ls-remote https://github.com/requires/auth \\\n>       2>&1 >/dev/null | egrep '^>|^< HTTP|^Authorization|requested URL'\n>   > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1\n>   * The requested URL returned error: 401 Authorization Required\n>   Username for 'https://github.com': foo\n>   Password for 'https://foo@github.com': \n>   > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1\n>   < HTTP/1.1 401 Authorization Required\n>   > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1\n>   Authorization: Basic Zm9vOmJhcg==\n>   < HTTP/1.1 401 Authorization Required\n>   * The requested URL returned error: 401\n> \n> So we get a 401, as expected, git prompts for the credentials and feeds\n> them directly to curl, but then we still get _two_ requests: we trigger\n> another 401, and only then does curl provide the authorization header to\n> the server.\n> \n> I'm not sure if that extra auth is intended or not.\n\ngit uses CURLAUTH_ANY which means: first try without authentication\n(CURLAUTH_NONE), if that fails it will try (I guess) CURLAUTH_BASIC|DIGEST|\nGSS|NTML and so on, and only then it will fail with the 401.\n\nIt seems that skipping CURLAUTH_NONE try is not possible even if it's\nnot a good idea when a username and possibly password is available.\nChanging CURLAUTH_ANY to skip CURLAUTH_NONE could also break other\nusers.\n\nSince netrc support really needs this one try from git to curl before\npassword prompt I guess in our case using HTTPS with git is simply not\nfeasible. Changing the corporate single sign-on policies is also hard\nso I will now try to get SSH transport running on the server.\n\nAccount locking will still be quite easy but hopefully only after\nmultiple false passwords to the SSH promp.\n\n-Mikko\n"}]}