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

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

git clone http://[email protected]/git/myapp.git
Initialized empty Git repository in /tmp/myapp/.git/
Password:
error: The requested URL returned error: 401 while accessing http://[email protected]/git/myapp.git/info/refs
fatal: HTTP request failed

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

[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-kerb 5.3-5


git authentication http kerberos
person Axel    schedule 06.08.2010    source источник
comment
Я почему-то сомневаюсь, что Git в настоящее время поддерживает аутентификацию через Kerberos. Просто чтобы подтвердить, ваш клиент работает на Debian Lenny?   -  person Phil Miller    schedule 07.08.2010
comment
Да клиент работает в ленни. Я знаю, что git не поддерживает аутентификацию через Kerberos, например SSO (с справочным билетом), но kerberos может эмулировать базовую аутентификацию в apache, и это не работает.   -  person Axel    schedule 07.08.2010

Ответы (3)


arrow_upward
3
arrow_downward

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

Это будет более надежно с Git 2.3.1 (Q1/Q2 2015): см. /a> автор Брайан М. Карлсон (bk2204):

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

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

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

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

Это будет с Git 2.32 (второй квартал 2021 г.) (см. вторую часть ниже): раньше при доступе к серверу с URL-адресом, например https://user:pass@site/, Git не возвращался к базовой аутентификации с использованием учетных данных. встроенный в URL-адрес после неудачной аутентификации Negotiate.
Теперь (Git 2.32) Git делает (пока нет, но скоро).

См. commit 1b0d954 (22 марта 2021 г.) от Кристофер Шенк (chschenk).
(объединено Хунио С. Хамано -- gitster -- в commit 5013802, 30 марта 2021 г.)

remote-curl: вернуться к базовой аутентификации в случае сбоя согласования

Подписано: Кристофер Шенк

Когда имя пользователя и пароль указаны в URL-адресе, подобном этому https://myuser:[email protected]/myrepo.git, и сервер поддерживает метод проверки подлинности для переговоров, git не возвращается к базовой аутентификации, и libcurl почти не пытается аутентифицироваться с помощью метода переговоров.

Прекратите использовать метод проверки подлинности Negotiate после первого сбоя, потому что, если он не сработает с первой попытки, он никогда не будет успешным.

Тем не менее, это все еще продолжается:

См. коммит ecf7b12, commit b694f1e (18 мая 2021 г.), автор Джефф Кинг (peff).
(Объединено Junio ​​C Hamano -- gitster -- в commit c69f2f8, 21 мая 2021 г.)

Revert "remote-curl: вернуться к базовой аутентификации в случае сбоя согласования

Отчетность: Бен Хамфрис
Подпись: Джефф Кинг

Это возвращает commit 1b0d954 (remote-curl: вернуться к базовой аутентификации, если Negotiate не удался, 2021- 03–22, Git v2.32.0-rc0 — слияние, указанное в пакет № 5).

Эта фиксация действительно исправляет ситуацию, для которой предназначалась (избегая согласования, даже если учетные данные были предоставлены в URL-адресе), но создает более серьезную регрессию: теперь мы никогда не попадаем в условное выражение, поскольку у нас были имя пользователя и пароль, мы пробовали их, но сервер все еще дал нам 401.

Это имеет два плохих последствия:

  1. мы никогда не вызываем credential_reject(), и поэтому поддельные учетные данные, сохраненные помощником, будут жить вечно
  2. мы никогда не возвращаем HTTP_NOAUTH,, поэтому пользователь получает сообщение об ошибке The requested URL returned error: 401 вместо Authentication failed.

Правильное выполнение этого кажется нетривиальным, поскольку мы не знаем, была ли проблема с аутентификацией Negotiate.
Поскольку это регрессия в грядущем выпуске v2.23.0 (для которого мы находимся в -rc0), давайте вернемся пока и работайте над исправлением отдельно.

(Обратите внимание, что это не чистый возврат; предыдущий коммит добавил тест, показывающий регрессию, так что теперь мы можем изменить его на expect_success).

person VonC    schedule 15.02.2015
comment
Если вы случайно не знаете, этого изменения еще нет в 2.5.1? - person kkm; 25.09.2015
comment
@kkm github.com/git/git/commit/ находится в git 2.3.1 - person VonC; 25.09.2015
comment
Спасибо, тогда похоже моя проблема в другом. Я буду искать больше и опубликую отдельный вопрос, если не смогу найти ничего, что могло бы помочь решить эту проблему. - person kkm; 25.09.2015

arrow_upward
1
arrow_downward

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

person Community    schedule 13.08.2010
comment
есть обходной путь? например, параметр git или переменная среды для принудительного базового? - person Jayen; 22.07.2012

arrow_upward
1
arrow_downward

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

echo http://x:[email protected] > ~/.git-credentials
git config --global credential.helper store

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

person Diego Woitasen    schedule 27.09.2013