Я следовал руководству по git, но у меня возникла странная проблема при попытке подключиться к github:
$ ssh -v git@github.com
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /c/Documents and Settings/mugues/.ssh/config
debug1: Applying options for github.com
debug1: Connecting to github.com [207.97.227.239] port 22.
debug1: connect to address 207.97.227.239 port 22: Attempt to connect timed out without establishing a connection
ssh: connect to host github.com port 22: Bad file number
Это мой конфигурационный файл под .ssh
Host github.com
User git
Hostname github.com
PreferredAuthentications publickey
IdentityFile "C:\Documents and Settings\mugues\.ssh\id_rsa"
TCPKeepAlive yes
IdentitiesOnly yes
Любая идея?
Ответы:
После этой проблемы я нашел решение, которое работает для меня:
Сообщение об ошибке:
Вы увидите сообщение о неверном номере файла только в Windows, используя оболочку MINGGW. Пользователи Linux просто получат Timed out.
Проблема:
SSH, вероятно, заблокирован на порту 22. Вы можете увидеть это, набрав
Как видите, состояние Filtered, что означает, что что-то его блокирует. Вы можете решить эту проблему, выполнив SSH к порту 443 (ваш брандмауэр / isp не заблокирует это). Также важно, чтобы вам нужен ssh для «ssh.github.com» вместо github.com. В противном случае вы будете отправлять отчеты на веб-сервер, а не на сервер ssh. Ниже приведены все шаги, необходимые для решения этой проблемы.
Решение:
(Прежде всего убедитесь, что вы сгенерировали свои ключи, как описано на http://help.github.com/win-set-up-git/ )
создайте файл ~ / .ssh / config (файл конфигурации ssh, расположенный в вашем пользовательском каталоге. На Windows, вероятно,
%USERPROFILE%\.ssh\config
Вставьте в него следующий код:
Сохраните файл.
Выполните ssh как обычно:
Обратите внимание, что мне не нужно указывать имя пользователя или номер порта.
источник
ssh: connect to host ssh.github.com port 443: Bad file number
.ssh/config
файла в Windows 7, убедитесь, что у вас есть User-Enviromental VarHOME
со%USERPROFILE%
значением as -> помог мне, когда мой ssh не смог его найтиКлючевая информация написана в ответе @ Сэма, но не очень заметна, поэтому давайте проясним это.
«Плохой номер файла» не информативен, это всего лишь признак запуска git ssh в Windows.
Строка, которая появляется даже без
-v
переключателя:на самом деле не имеет значения .
Если вы сосредоточитесь на этом, вы потратите время впустую, так как это не подсказка о том, что является реальной проблемой, а просто эффект запуска git ssh в Windows. Это даже не признак неправильной установки или конфигурации git или ssh. Действительно, игнорируй это .
Та же самая команда в Linux произвела вместо меня это сообщение, которое дало реальный намек на проблему:
Актуальное решение: игнорируйте «неверный номер файла» и получите больше информации
Сосредоточьтесь на строках, добавляемых
-v
в командной строке. В моем случае это было:Моей проблемой была опечатка в IP-адресе, но ваша может отличаться.
Это вопрос о "неправильном номере файла" или о многих причинах, по которым время ожидания соединения может истечь?
Если кто-то может доказать, что «неверный номер файла» появляется только тогда, когда действительной причиной является «тайм-аут соединения», то имеет смысл обратиться к вопросу, почему истекло время ожидания соединения.
До этого «неверный номер файла» является только общим сообщением об ошибке, и на этот вопрос полностью отвечают, говоря «игнорируйте его и ищите другие сообщения об ошибках».
РЕДАКТИРОВАТЬ: Qwertie упомянул, что сообщение об ошибке действительно является общим, как это может произойти и при «Отказ в соединении». Это подтверждает анализ.
Пожалуйста, не загромождайте этот вопрос общими подсказками и ответами, они не имеют ничего общего с реальной темой (и заголовком) этого вопроса, которая называется «Ошибка Git SSH:« Соединиться с хостом: неверный номер файла »». Если при использовании у
-v
вас есть более информативное сообщение, заслуживающее своего собственного вопроса, то откройте еще один вопрос, тогда вы сможете сделать ссылку на него.источник
scp
командную строку добавило «debug1: connect по адресу 216.34.181.70 порт 22: Соединение отклонено» до «Плохой номер файла», так что это не всегда ошибка «тайм-аут».Это сработало для меня:
источник
Возможно, ваш брандмауэр или блокирующее приложение (PeerBlock и т. Д.) Блокирует ваш порт
источник
Вы также можете попробовать:
чтобы увидеть, если у вас есть подключение к серверу. Я увидел это сообщение, и в итоге VPN, на которой я был, блокировал доступ. Отключил от ВПН и мне было хорошо идти.
источник
Я обнаружил, что это происходит, когда ваше соединение плохое. У меня было это несколько минут назад, когда я нажимал на репо, оно продолжало давать сбой, и через некоторое время связь оборвалась.
После того, как это вернулось, толчок немедленно прошел.
Я полагаю, что это может быть вызвано либо обрывом связи с вашей или их стороны.
источник
bad file number
ошибке, когда соединение обрывается.Если SSH заблокирован более 22
просто обновите ваш
origin
до httpsgit remote set-url origin https://github.com/ACCOUNT_NAME/REPO_NAME.git
убедитесь, что были внесены изменения
git remote -v
источник
У меня была та же проблема, и я пытался найти любое решение, которое смог найти, но ни одно не помогло. В конце концов я попытался выйти из Git Bash и снова открыть его, и все работало отлично.
Итак, попробуйте выйти из Git Bash и снова открыть его.
источник
Попробуйте выйти из экземпляра git bash, через который вы выполнили настройку, и попробуйте снова открыть. В конечном итоге это сработало для меня.
источник
В Windows я попытался выйти из git bash и перезапустить, но ничего не получилось, в конце концов я (frustated) перезапустился, и это сработало в следующий раз :)
источник
Дважды проверьте, что вы опубликовали свои открытые ключи через интерфейс администрирования GitHub.
Затем убедитесь, что порт 22 как-то не заблокирован (как показано в этом вопросе )
источник
В моем случае IP-адрес нашего хоста git изменился.
Простая очистка кеша DNS устранила проблему.
источник
Создание файла конфигурации для использования порта 443 не работает для меня. Наконец я попытался отключить соединение Wi-Fi, включить его снова, и проблема исчезла. Weird. Глупое решение, но оно может кому-то помочь :)
источник
Проверьте ваш пульт с помощью git remote -v Что-то вроде ssh: /// gituser @ myhost: /git/dev.git
неправильно из-за тройной косой черты ///
источник
Я видел эту проблему при доступе к bitbucket в корпоративной сети, в то время как git отлично работает в домашней сети.
Я использовал протокол https, чтобы обойти это.
Пожалуйста, используйте соответствующие слова, чтобы заменить «myaccount» и «myrepo».
источник
Следующее решение работало для меня, когда я пытался подключиться к SSH к экземпляру AWS EC2 Ubuntu с моего компьютера под управлением Windows 7 (32-разрядная версия) за корпоративным брандмауэром, настроив прокси-сервер.
Добавьте следующий блок в
C:\Users\<YOUR_WINDOWS_USER>\.ssh\config
файлВам нужно будет добавить аналогичную конфигурацию для каждого хоста, в который вы хотите использовать SSH.
источник
У меня была проблема, когда у меня было открытое FileZilla-Connection в Windows. Закрыто FileZilla -> Проблема решена.
источник
Это простое решение для сохранения набора текста, вы можете легко использовать следующие шаги в git bash:
(1) создать удаленный репозиторий
Примечание. Если ваш пароль содержит знак «@», используйте вместо него «% 40».
(2) Затем сделайте все, что вы хотите с удаленным хранилищем
источник
В моем случае помогла просто перезагрузка WiFi роутера.
источник