Git аутентификация через apache_mod_krb - PullRequest
Новая
       6

Git аутентификация через apache_mod_krb

4 голосов
/ 06 августа 2010

Я использую git-репо с git-http-backend.В apache2 у меня есть местоположение, что требует аутентификации для клонирования и push-действий.Когда я защищал его местоположение с помощью AuthType Basic, все работало нормально, git проходит аутентификацию и может клонировать и передавать, но если я изменил тип на KerberosV5, git не сможет получить доступ к репо с правильными учетными данными.Если я использую свой браузер, у меня есть доступ к местоположению, что защищать Kerberos. 

git clone http://user@mydomain.com/git/myapp.git
Initialized empty Git repository in /tmp/myapp/.git/
Password:
error: The requested URL returned error: 401 while accessing http://user@mydomain.com/git/myapp.git/info/refs
fatal: HTTP request failed

и в журналах ошибок apache 

[Fri Aug 06 17:15:50 2010] [debug] src/mod_auth_kerb.c(1579): [client 192.168.12.153]  kerb_authenticate_user entered with user (NULL) and auth_type KerberosV5 
[Fri Aug 06 17:15:50 2010] [debug] src/mod_auth_kerb.c(1579): [client 192.168.12.153]kerb_authenticate_user entered with user (NULL) and auth_type KerberosV5

git-core 1: 1.7.1-1~ bpo50 + 1 apache2 2.2.9-10 + lenny8 libapache2-mod-auth-curb 5.3-5

Ответы [ 3 ]

3 голосов
/ 15 февраля 2015

Проблема в curl, потому что git в debian был скомпилирован с параметром curl ANY_AUTH, и когда клиент git пытается подключиться к веб-серверу и сначала попросить его выполнить аутентификацию, а он не может этого сделать, git не пробует базовую аутентификацию.

Это будет более надежно с Git 2.3.1 (Q1 / Q2 2015): см. commit 4dbe664 by brian m. карлсон (bk2204) :

remote-curl: возврат к Basic auth, если Negotiate не удается

Серверы Apache, использующие mod_auth_kerb, могут быть настроены для разрешения пользователю аутентифицироваться либо с помощью Negotiate (используя тикет Kerberos), либо Обычная аутентификация (с использованием пароля Kerberos). Часто один будет хотите использовать согласование проверки подлинности, если оно доступно, но отступите к базовой аутентификации, если билет отсутствует или истек.

Однако libcurl будет очень стараться использовать что-то отличное от Basic аутентификация, даже через HTTPS.
Если предлагается Basic и что-то еще, libcurl никогда не будет пытаться использовать Basic, даже если другая опция не удалась.
Научите клиентский код HTTP перестать пробовать механизмы аутентификации, которые не используйте пароль (в настоящее время Negotiate) после первого сбоя, поскольку, если они потерпели неудачу в первый раз, они никогда не преуспеют .

1 голос
/ 28 сентября 2013

Это что-то странное в libcurl, а не проблема в Git.Есть обходной путь.Libcurl не включает никакой код аутентификации, если вы не передаете имя пользователя и пароль в библиотеку.Это происходит, если вы также используете переговоры (kerberos), которое не требует имени пользователя и пароля.Простое решение: 

echo http://x:x@git.example.com > ~/.git-credentials
git config --global credential.helper store

x: x - это имя пользователя и пароль.Вы можете использовать любую случайную строку там.Требуется только включить путь к коду аутентификации в libcurl.Тогда Kerberos будет работать (у меня работает :)).

1 голос
/ 13 августа 2010

Проблема в curl, потому что git в debian был скомпилирован с параметром curl ANY_AUTH, и когда клиент git пытается подключиться к веб-серверу и сначала попросить его выполнить аутентификацию, а он не может этого сделать, git не пробует базовую аутентификацию, потому что basic более низкая безопасность, чем переговоры. Когда я пытаюсь использовать curl --anyauth, я тоже могу получить данные с веб-сервера, но если я изменяю - basic, все работает нормально, проблема в том, что я не могу сказать git, что должен использовать auth.

...