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

Клонирование моих операций репо; отталкивание назад к нему не происходит.

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://[email protected]':
remote: Anonymous access to slimsnerdy/testy.git denied.
fatal: Authentication failed for 'https://github.com/slimsnerdy/testy.git/'

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

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

ОТВЕТЫ

Ответ 1

В брандмауэре вашей компании установлен прокси-сервер, который действует как человек посередине. С этой целью он создает сертификаты для сайтов, которые вы посещаете, например, 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. Run 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 вы можете дополнительно исследовать обмен данными. Особенно для последнего из трех запросов, показанных выше, вы должны увидеть что-то подобное на вкладке "Заголовки":

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

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

Ответ 2

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

git config --global http.sslVerify false

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

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

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

git config --unset http.sslVerify

Ответ 3

Для тестирования отключите временный 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