Согласно базе знаний bitbucket, это также может быть вызвано тем, что владелец репозитория превысил лимит плана. .

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

Вы можете получить больше информации с

# Windows
set GIT_CURL_VERBOSE=1
set GIT_TRACE_PACKET=2

# Unix
export GIT_CURL_VERBOSE=1
export GIT_TRACE_PACKET=2

А затем попробуйте git push.

Дважды проверьте настройки прокси-сервера, если он у вас есть.

Примечание: git 2.8 (март 2016 г.) добавляет дополнительную информацию об ошибке 35:

См. коммит 0054045 (14 февраля 2016 г.) от Шон Пирс (spearce).
^{(объединено Junio ​​C Hamano -- gitster -- в commit 97c49af, 24 февраля 2016)}

remote-curl: включить curl_errorstr при ошибках установки SSL

Для curl ошибки 35 (CURLE_SSL_CONNECT_ERROR) пользователям нужен дополнительный текст, хранящийся в CURLOPT_ERRORBUFFER, чтобы отладить, почему соединение не запускается.
Это curl_errorstr внутри http.c, поэтому включите его в сообщение, если оно не пустое.

Также ознакомьтесь с частые причины появления этого сообщения:

Если он работал раньше и не работает сегодня, возможно, срок действия закрытого ключа SSL истек на стороне BitBucket (см. ниже, причина № 3), но здесь это не так (сертификат действителен до тех пор, пока 03.12.2014).

Целевой сайт не любит протокол

Выполнение запроса, подобного следующему, приводит к ошибке «Неизвестный протокол SSL»:

curl --sslv2 https://techstacks-tools.appspot.com/

Почему? Что ж, в данном случае это связано с тем, что сайт инструментов techstacks не поддерживает SSLv2, что приводит к ошибке curl (35).

Целевой сайт не любит шифр

Возможно, вы пытаетесь подключиться к сайту с помощью шифра SSL, который сайт настроен на отклонение.
Например, анонимные шифры обычно отключены на сайтах с шифрованием SSL, которые предназначены для клиентов. (Многие из нас устанавливают политику общего отклонения для любого веб-сайта, зашифрованного с помощью SSL, независимо от его назначения.)
Следующая командная строка «может» также привести к ошибке curl (35):

curl --ciphers ADH-RC4-MD5 https://some_web_site.some_domain.com/

К сожалению, тип ответа об ошибке, который вы можете получить от curl, во многом зависит от сервера ssl. На некоторых сайтах вы получите сообщение об ошибке «Неизвестный протокол SSL», но на моем сайте techstacks-tools я получаю:

curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

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

Попробуйте подключиться к сайту с помощью шифра, поддерживаемого сайтом. Не знаете, какой шифр использовать? Что ж, позвольте представить вам мой тестер шифрования SSL для шифрования...

Срок действия закрытого ключа SSL истек

Я столкнулся с этим ранее сегодня, работая со старым сайтом WebSeAL.
В IBM GSKit вы можете указать, как долго действует пароль закрытого ключа. После достижения определенной даты вы по-прежнему сможете запускать webseal и прослушивать порт 443 (или любой другой, на который вы настроили значение https-порта), но вы не сможете успешно согласовать сеанс SSL.
В сегодняшних условиях В этом случае старый экземпляр WebSEAL использовал файл kdb с истекшим сроком действия и пароль закрытого ключа с истекшим сроком действия. После замены на правильную, более свежую версию все снова заработало.

Неверное перенаправление

Некоторым интернет-провайдерам и поставщикам DNS нравится перехватывать ваши неудачные DNS-запросы, чтобы перенаправить вас на страницу в стиле результатов поисковой системы, предлагающую вам альтернативные URL-адреса или «Вы имели в виду ...?» результаты встречного запроса.
Если вы видите такое сообщение об ошибке:

 error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol, 

это может быть связано с тем, что вы неправильно ввели имя хоста или имя хоста еще не указано в вашем DNS. Вы можете проверить это с помощью простого «host» или «nslookup».

Примечание (август 2015 г.): Git 2.6+ (3 квартал 2015 г.) позволит явно указать версию SSL:

http: добавлена ​​поддержка указания версии SSL

См. коммит 01861cb (14 августа 2015 г.) от Элия Пинто (devzero2000).
Помощь: Эрик Солнечный свет (sunshineco).
^{(Объединено Хунио С. Хамано -- gitster -- в commit ed070a4, 26 августа 2015 г.)}

http.sslVersion

Версия SSL, которую следует использовать при согласовании соединения SSL, если вы хотите установить значение по умолчанию.
Доступная версия и версия по умолчанию зависят от того, была ли libcurl создана для NSS или OpenSSL, а также от конкретной конфигурации используемой криптобиблиотеки. Внутри это устанавливает опцию 'CURLOPT_SSL_VERSION'; см. документацию libcurl для получения более подробной информации о формате этой опции и поддерживаемой версии ssl.
На самом деле возможные значения этой опции:

• sslv2
• sslv3
• tlsv1
• tlsv1.0
• tlsv1.1
• tlsv1.2

Может быть переопределено переменной среды 'GIT_SSL_VERSION'.
Чтобы заставить git использовать версию ssl libcurl по умолчанию и игнорировать любую явную опцию http.sslversion, задайте для GIT_SSL_VERSION пустую строку.

Установка следующей настройки git исправила это для меня

git config --global --add http.sslVersion tlsv1.0

Я предполагаю, что корпоративному прокси-серверу не понравился протокол шифрования по умолчанию.

Во многих случаях это связано с проблемами прокси. Если это так, просто настройте свой git-прокси

git config --global http.proxy HOST:PORT

Эта ошибка также появляется, когда сервер не работает. Письмо от техподдержки по проблеме:

«У нас произошел сбой, который повлиял на трафик веб-сайта, а также на трафик Mercurial и Git через HTTPS. Однако SSH не пострадал. Не стесняйтесь проверить эту страницу для получения дополнительной информации:

http://status.bitbucket.org/"

Так что попробуйте еще раз позже, и это может сработать само собой. Сделал для меня

Я получал это за корпоративным прокси.

Решено:

git config http.sslVerify "false"

У меня такая же проблема. С последней версией git и без прокси.

Я починил это:

• войти в GitHub
• войдите в интерфейс: «Личные настройки», затем нажмите «Ключи SSH», пожалуйста, подтвердите, поместили ли вы «id_rsa.pub», сгенерированный командой
• 'ssh-keygen -t rsa' в Windows в github --> GIT BASH
• «Добавить ключ SSH» и вставить в него «id_rsa.pub».

Дополнительная информация: создать ключ

скопируйте ключ

Я столкнулся с этой проблемой, когда использовал контроль версий в Android Studio 2.1.3, сценарий, с которым я столкнулся, был следующим:

1- я открыл IDE и щелкнул значок "обновить/вытащить" (Ctrl+T)

2- он не запрашивал мастер-пароль, и это не удалось, выдало мне эту ошибку:

Unknown SSL protocol error in connection to bitbucket.org:443

3- я попытался получить репозиторий (щелчок правой кнопкой мыши > git > репозиторий > выборка)

4- он попросил у меня мастер-пароль, и я ввел его

5- он пытался получить, но снова и снова терпел неудачу

6- я перезапустил студию Android

7- я попытался получить репозиторий (щелчок правой кнопкой мыши > git > репозиторий > выборка)

8- он попросил у меня мастер-пароль, и я ввел его

9- теперь все хорошо, все идет хорошо

Вывод :

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

наличие 2 компьютеров,

номер один — моя корпоративная лаборатория, подключенная через VPN к нашей корпоративной сети. Это все равно, что находиться внутри компании за большими брандмауэрами и кучей маршрутизаторов, с людьми, внутренними и внешними (даже телекоммуникационными) возиться с сетью и брандмауэром, и чтобы связаться, я должен предоставить учетные данные, такие как прокси-пользователь и пароль и даже тогда, иногда он работает, а иногда нет.

т.е. я могу получить доступ через брандмауэр, используя загрузки SVN JSVN MAVEN, загрузки ANT, и я могу использовать git clone http://git. .. репо.

Но я не могу сделать git clone https://git... репо. В этом последнем случае я получаю эту ошибку.

Компьютер номер два на месте со мной — это моя маленькая домашняя лаборатория, ничего особенного, подключенная через глобальную сеть к www и работающая со всеми упомянутыми выше инструментами плюс git clone https://git... репозиторий работает как нюх, не делая ничего особенного.

Вывод: Нахождение за «каким-то образом управляемым брандмауэром» часто является причиной проблем. Чтобы выяснить это, возьмите свою маленькую незащищенную лабораторию и подключитесь к Интернету из дома, и если она работает, не тратьте время на ваших охранников, они будут работать неделями, если только вы не знаете, почему это не работает в вашем случай, и, возможно, вы можете поделиться с переносным диском клонированным репозиторием git.

Йозеф - старею, тратя время в таких ситуациях ;-)

Я использую tortoiseGit. У меня такая же проблема. Затем в настройках push я снял флажок «клавиша автозагрузки», попытался нажать, затем снова проверил, нажал, и это сработало. А если серьезно, я не знаю, почему.

выполнять

nc -v -z <git-repository> <port>

ваш вывод должен выглядеть так

"Connection to <git-repository> <port> port [tcp/*] succeeded!"

если вы получите

connect to <git-repository> <port> (tcp) failed: Connection timed out

Вам нужно отредактировать файл ~/.ssh/config. Добавьте что-то вроде следующего:

Host example.com
Port 1234

Корпоративный HTTP-прокси, за которым я сейчас нахожусь, время от времени выдает эту ошибку. Я могу исправить это, просто зайдя на сайт bitbucket.org в браузере и повторив команду. Понятия не имею, почему это работает, но мне это помогает (по крайней мере, временно).

Если вы столкнулись с «Неизвестной ошибкой протокола SSL при подключении к bitbucket.org: 443» и находитесь в Китае, возможно, github временно заблокирован брандмауэром. Вы можете попробовать использовать VPN, это сработает. Удачи!

Эта ошибка возникает у меня, когда я загружаю большое количество источников (около 700 МБ), затем я пытаюсь частично загрузить его, и он был успешно отправлен.

У меня была такая же проблема, я попробовал все изменения настроек SSL, которые приведены здесь. Если вы находитесь в корпоративной сети и ключи ssh используются в таких инструментах, как Gerrit. 1. Получите ключ ssh. 2. Посетите Bitbucket и перейдите в «Профиль» >> «Настройки» >> «Ключи SSH» >> «Добавить ключ».

После добавления ключа ssh попробуйте нажать еще раз.

Мне удалось решить эту проблему, запустив

git config --list --show-origin

а затем увидев, что у меня есть строка:

файл: c:/Пользователи/пользователь/.gitconfig http.sslversion=sslv3

Я отредактировал файл c:/Users/user/.gitconfig и удалил строку [http] и строку sslversion=sslv3, и это исправило это для меня.