git clone работает, но push не работает после замены SSL-сертификата за брандмауэром

Question

Клонирование моих репо работ;нажатие на нее не работает.

1-е клонирование не сработало:

git clone https://github.com/slimsnerdy/testy.git
Cloning into 'testy'...
fatal: unable to access 'https://github.com/slimsnerdy/testy.git/': SSL certificate problem: self signed certificate in
certificate chain

Поэтому я добавил в файл .gitconfig следующий пользовательскийсертификат:

[http]
    sslCAInfo = U:/ca-bundle.crt

Теперь клонирование работает:

Cloning into 'testy'...
remote: Counting objects: 25, done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 25 (delta 8), reused 6 (delta 1), pack-reused 0
Unpacking objects: 100% (25/25), done.

Хорошо, теперь нажимаем:

new-item test.txt
git add *
git commit -m "push test"
git push
Username for 'https://github.com': slimsnerdy
Password for 'https://slimsnerdy@github.com':
remote: Anonymous access to slimsnerdy/testy.git denied.
fatal: Authentication failed for 'https://github.com/slimsnerdy/testy.git/'

Когда я пытаюсь протолкнуть через личный hotpot с помощью моего телефона (обход корпоративного брандмауэра), он выдвигается нормально.

Почему clone работает с пользовательским сертификатом, а не push?Я хочу обойти это без использования SSH.

Answer 1

Для тестирования отключите временно SSL для вашего репозитория с помощью:

git config http.sslVerify false

Затем также проверьте, синхронизируются ли ваши системные часы, так как это может повлиять на работу проверки SSL, вы можете получить что-то вроде:

[SSL certificate problem, verify that the CA cert is OK. 
Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed])

Попробуйте использовать ntp / chrony для синхронизации системных часов.

Затем, чтобы получить сертификат, вы можете использовать:

openssl s_client -showcerts -connect github.com:443 < /dev/null

Получите все в -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- и создайте cert.pem

Затем используйте этот файл, как вы пытаетесь в http.sslCAInfo:

git config http.sslCAInfo /path/to/cert.pem

После того, как сделанопопробуйте включить обратно http.sslVerify:

git config --unset http.sslVerify

Answer 2

Брандмауэр вашей компании установил прокси, который действует как человек посередине .Для этого он создает сертификаты для посещаемых вами сайтов, например, github.com.Эти сертификаты, очевидно, имеют другого эмитента (внутренний центр сертификации вашей компании), которому git-клиент по умолчанию не будет доверять.Отключение sslVerify заставляет клиента git принимать любой сертификат от любого эмитента.Это потенциально опасно.Ваш первоначальный подход - добавить CA вашей компании в список эмитентов, которым доверяет git-клиент, - ИМХО - лучший способ позволить вашему git-клиенту общаться с github.com из-за брандмауэра вашей компании.

Так почемуРазве эта настройка не позволяет вам push?Другие постеры упустили из виду то, что ошибка в этом случае , а не ошибка SSL.Только ваш клиент видит сертификат вашей компании.Если это решено, это решено.Github не видит этот сертификат.Поэтому дальнейшая подстройка с настройками SSL не поможет.

Я мог бы воспроизвести ваш случай, поскольку впервые увидел проблему с самозаверяющим сертификатом SSL, которая исчезла, когда я добавил сертификат прокси-сервера в sslCAInfo.Плохая новость: я мог не воспроизвести Ошибка аутентификации Ошибка.Толчок к GitHub просто работал.Хорошая новость: можно нажать на github из настроек, аналогичных вашим.

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

Пожалуйста, обратитесь к специалистам по ИТ-безопасности в вашей компании.Они должны уметь выяснить, накладывает ли прокси ограничения на доступ для github или для определенных команд git.

Обновление

Маршрутизация трафика Git через Fiddler может быть выполнена следующим образом (используйте git из командной строки):

1. Запустите Fiddler
2. В git bash перейдите в рабочую директорию cd и добавьте опции -c http.sslVerify=false -c http.proxy=127.0.0.1:8888 в команду git.

Пример:

$ git -c http.sslVerify=false -c http.proxy=127.0.0.1:8888 push

В Fiddler вы должны увидеть что-то вроде:

2   200 HTTP    Tunnel to   github.com:443  0           git-remote-https:6512           
3   401 HTTPS   github.com  /xxx/xxxx.git/info/refs?service=git-receive-pack [...]      
4   200 HTTPS   github.com  /xxx/xxxx.git/info/refs?service=git-receive-pack [...]          

Или, экспортированные с краткой сводкой (Ctrl / Shift / T):

CONNECT http://github.com:443
200 Connection Established ()

GET https://github.com/xxx/xxxx.git/info/refs?service=git-receive-pack
401 Authorization Required (text/plain)

GET https://github.com/xxx/xxxx.git/info/refs?service=git-receive-pack
200 OK (application/x-git-receive-pack-advertisement)

На правой панели Fiddler Web Debugger вы можете дополнительно изучить данные, которыми обменивались.Специально для последнего из трех запросов, показанных выше, вы должны увидеть что-то подобное на вкладке «Заголовки»:

GET /xxx/xxxx/info/refs?service=git-receive-pack HTTP/1.1
Host: github.com
Authorization: Basic XyzzY1337qQ=
User-Agent: git/2.13.0.windows.1
Accept: */*
Accept-Encoding: gzip
Pragma: no-cache

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

Answer 3

Я уверен, что это может вам помочь.

git config --global http.sslVerify false

Как вы можете догадаться, эта команда изменяет настройку ssl для отключения проверки ssl.

Предупреждение: этот метод небезопасен.

Если вы хотите его вернуть, вы можете включить его в любое время.

git config --unset http.sslVerify