proxyAuthMethod у Git вимагає імені користувача проксі

Перевірте ім'я користувача проксі, вибраний метод, перевизначення з середовища та версію Git, коли налаштування proxyAuthMethod здається неефективним.

Ви додаєте http.proxyAuthMethod, повторюєте клонування і досі бачите 407. Налаштування має задокументовану умову, яку легко пропустити: налаштований рядок проксі повинен містити ім'я користувача.

Ім'я користувача не обов'язково супроводжується буквальним паролем у URL. Git може отримати відсутній пароль через свій механізм облікових даних. Ідентичність маршрутизації та метод автентифікації все одно мають стосуватися потрібного проксі.

Перевірте чотири вхідні дані разом

  1. Фактичний URI проксі без пароля.
  2. Метод, вибраний для цього проксі.
  3. Будь-яке перевизначення для окремого remote або перевизначення середовища GIT_HTTP_PROXY_AUTHMETHOD.
  4. Версія Git і можливості її HTTP-бекенду.

Поточний Git документує методи, зокрема anyauth, Basic, Digest, Negotiate і NTLM. Вибір одного з них не додає відсутньої підтримки пов'язаному бекенду. Корпоративному адміністратору також не слід послаблювати політику проксі через те, що клієнт налаштований на інший метод.

Старіші звіти охоплюють версії, у яких не було реалізовано опцію, що копіюється. Довільний ключ конфігурації можна зберегти без доказів того, що поточне передавання його використовує. Прочитайте документацію для відповідної версії та відредагований обмін.

Нарешті, облікові дані репозиторію — це пізніший зв'язок. Токен хостингу Git не задовольняє запит проксі. Вимкнення перевірки TLS репозиторію також не змушує проксі прийняти вибрану схему автентифікації. Спершу встановіть цей обмін, а потім діагностуйте будь-яку відповідь репозиторію, що надійде далі.

Схожі статті