Git Ошибка SSH: "Подключиться к хосту: номер плохого файла"

Я следил за git guide, но у меня есть эта странная проблема при попытке подключиться к github:

$ ssh -v [email protected]
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

Любая идея?

Ответ 1

После этой проблемы я сам нашел решение, которое работает для меня:

Сообщение об ошибке:

    ssh -v [email protected]
    OpenSSH_5.8p1, OpenSSL 1.0.0d 8 Feb 2011
    debug1: Connecting to github.com [207.97.227.239] port 22.
    debug1: connect to address 207.97.227.239 port 22: Connection timed out
    ssh: connect to host github.com port 22: Connection timed out
    ssh: connect to host github.com port 22: Bad file number

Вы увидите сообщение о неверном номере файла только в Windows, используя оболочку MINGGW. Пользователи Linux просто получат Timed out.

Проблема:

SSH, вероятно, заблокирован на порту 22. Вы можете увидеть это, набрав

    $nmap -sS github.com -p 22
    Starting Nmap 5.35DC1 ( http://nmap.org ) at 2011-11-05 10:53 CET
    Nmap scan report for github.com (207.97.227.239)
    Host is up (0.10s latency).
    PORT   STATE    SERVICE
    22/tcp ***filtered*** ssh

    Nmap done: 1 IP address (1 host up) scanned in 2.63 seconds

Как видите, состояние 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

Вставьте в него следующий код:

    Host github.com
    User git
    Hostname ssh.github.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_rsa
    Port 443

Сохраните файл.

Выполните ssh как обычно:

$ssh -T github.com 
    $Enter passphrase for key '.......... (you can smile now :))

Обратите внимание, что мне не нужно указывать имя пользователя или номер порта.

Ответ 2

Ключевая информация написана в ответе @Sam, но не очень актуальна, поэтому дайте понять.

"Плохой номер файла" не является информативным, это только признак запуска git ssh в Windows.

Линия, которая появляется даже без переключателя -v:

ssh: connect to host (some host or IP address) port 22: Bad file number

на самом деле нерелевантно.

Если вы сосредоточены на этом, вы будете тратить свое время, поскольку это не намек на то, что представляет собой реальная проблема, а просто эффект запуска git ssh в Windows. Это даже не знак того, что установка или конфигурация git или ssh неверны. Действительно, игнорировать его.

Сама же команда для Linux создала вместо этого это сообщение для меня, которое дало реальный намек на проблему:

ssh: connect to host (some host or IP address) port 22: Connection timed out

Фактическое решение: игнорировать "неправильный номер файла" и получить дополнительную информацию

Сосредоточиться на строках, добавленных с помощью -v в командной строке. В моем случае это было:

debug1: connect to address (some host or IP address) port 22: Attempt to connect timed out without establishing a connection

Моя проблема была опечаткой в ​​IP-адресе, но ваши могут отличаться.

Является ли этот вопрос о "плохом номере файла" или о многих причинах, по которым соединение может истекать?

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

До тех пор, "неправильный номер файла" является только общим сообщением об ошибке, и на этот вопрос отвечает полный ответ: "игнорировать его и искать другие сообщения об ошибках".

EDIT: Qwertie упомянул, что сообщение об ошибке действительно является общим, так как это может произойти и при "соединении". Это подтверждает анализ.

Пожалуйста, не мешайте этому вопросу с общими подсказками и ответами, они не имеют никакого отношения к фактической теме (и названию) этого вопроса, которая является "Git Ошибка SSH:" Подключиться к хосту: Плохой номер файла "". Если вы используете -v, у вас есть более информативное сообщение, которое заслуживает их собственного вопроса, а затем откройте другой вопрос, тогда вы можете сделать ссылку на него.

Ответ 3

Это сработало для меня:

ssh -v [email protected] -p 443

Ответ 4

Возможно, ваш брандмауэр или приложение-блокиратор (PeerBlock и т.д.) блокируют ваш порт

Ответ 5

Вы также можете попробовать:

telnet example.com 22

чтобы узнать, есть ли у вас подключение к серверу. Я увидел это сообщение, и в итоге я оказался в VPN, на котором я был, блокировал доступ. Отключен от VPN, и мне было хорошо идти.

Ответ 6

Я обнаружил, что это происходит, когда ваше соединение плохое. У меня было это несколько минут назад, когда я нажимал на свое репо, он продолжал терпеть неудачу, и через некоторое время соединение опустилось.

После того, как он вернулся, нажатие сразу же прошло.

Я считаю, что это может быть вызвано либо падением в соединении с вашей стороны, либо с вашей стороны.

Ответ 7

Если SSH заблокирован более чем 22

просто обновите свой origin до https

git remote set-url origin https://github.com/ACCOUNT_NAME/REPO_NAME.git

проверить, что изменения были сделаны

git remote -v

Ответ 8

У меня была одна и та же проблема, и я попытался найти все, что мог найти, но никто не работал. В конце концов, я попытался выйти из Git Bash и снова открыть его, и все сработало отлично.

Итак, попробуйте выйти из Git Bash и снова открыть его.

Ответ 9

Попробуйте выйти из экземпляра git bash, через который вы создали настройку и попробуйте повторно открыть. В конечном итоге это помогло мне.

Ответ 10

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

Затем убедитесь, что порт 22 не заблокирован (как в этом вопросе)

Ответ 11

В окнах я попытался сделать quit git bash и повторно запустить, но не работал, наконец, я (скремблировал) сделал перезагрузку, и он работал в следующий раз:)

Ответ 12

В моем случае IP-адрес нашего хоста git изменился.

Просто очистка кэша DNS устранила проблему.

Ответ 13

Создание файла конфигурации для использования порта 443 не помогло мне. Наконец, я попытался отключить соединение Wi-Fi, снова включить его, и проблема исчезла. Weird. Глупый раствор, но он может помочь кому-то:)

Ответ 14

Проверьте свой пульт дистанционного управления с помощью git remote -v Что-то вроде ssh:///gituser @myhost:/ git/dev.git

неверно из-за тройного///слэша

Ответ 15

Я видел эту проблему, когда я обращаюсь к bitbucket в корпоративной сети, а git отлично работает в домашней сети.

$ git pull
ssh: connect to host bitbucket.org port 22: Bad file number
fatal: Could not read from remote repository.

Я использовал протокол https для обхода этого.

$ git pull https://[email protected]/myaccount/myrepo.git
Password for 'https://[email protected]':

Пожалуйста, используйте соответствующие слова для замены "myaccount" и "myrepo".

Ответ 16

Следующее решение сработало для меня, когда я попытался подключиться к SSH к экземпляру AWS EC2 Ubuntu с моего компьютера с Windows 7 (32-разрядная версия) за настройкой корпоративного брандмауэра Proxy-

Добавьте следующий блок в C:\Users\<YOUR_WINDOWS_USER>\.ssh\config Ssh C:\Users\<YOUR_WINDOWS_USER>\.ssh\config file-

> Host *
>      ProxyCommand "C:/Program Files/Git/mingw32/bin/connect.exe" -H <YOUR_PROXY_SERVER_HOST>:<YOUR_PROXY_SERVER_PORT> %h %p
>      IdentityFile "<PATH_OF_YOUR_IDENTITY_FILE>"
>      TCPKeepAlive yes
>      IdentitiesOnly yes
>     
>     Host <SERVER_HOST_NAME_OR_IP_YOU_WANT_TO_SSH_INTO>
>      Port <SERVER_HOST_PORT_YOU_WANT_TO_SSH_INTO>
>      Hostname <SERVER_HOST_NAME_OR_IP_YOU_WANT_TO_SSH_INTO>

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

Ответ 17

У меня возникла проблема, когда у меня было открытое FileZilla-Connection в Windows. Закрыто FileZilla → Проблема решена.

Ответ 18

Это простое решение для сохранения некоторой типизации вы можете легко использовать следующие шаги в git bash.

(1) создать удаленный репозиторий

git remote add origin https://{your_username}:{your_password}@github.com/{your_username}/repo.git

Примечание. Если ваш пароль содержит знак "@", используйте вместо этого "% 40"

(2) Затем сделайте все, что захотите, в удаленном репозитории

ex:- git push origin master

Ответ 19

В моем случае вам просто удалось перезапустить WiFi-маршрутизатор.