Błąd Git SSH: „Połącz z hostem: zły numer pliku”

Postępowałem zgodnie z przewodnikiem po git, ale mam ten dziwny problem podczas próby połączenia z 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

To jest mój plik konfiguracyjny w .ssh

Host github.com
    User git
    Hostname github.com
    PreferredAuthentications publickey
    IdentityFile "C:\Documents and Settings\mugues\.ssh\id_rsa"
    TCPKeepAlive yes
    IdentitiesOnly yes

Dowolny pomysł?

Po tym, jak sam miałem ten problem, znalazłem rozwiązanie, które działa dla mnie:

Komunikat o błędzie:

    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

Komunikat o złym numerze pliku będzie widoczny tylko w systemie Windows używającym powłoki MINGGW. Użytkownicy Linuksa zostaną po prostu przekroczeni.

Problem:

SSH jest prawdopodobnie zablokowane na porcie 22. Możesz to zobaczyć wpisując

    $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

Jak widać stan jest filtrowany, co oznacza, że ​​coś go blokuje. Możesz rozwiązać ten problem, wykonując SSH na porcie 443 (twój firewall / ISP tego nie zablokuje). Ważne jest również, aby ssh kierować na „ssh.github.com” zamiast na github.com. W przeciwnym razie zgłosisz się do serwera WWW zamiast do serwera ssh. Poniżej znajdują się wszystkie kroki potrzebne do rozwiązania tego problemu.

Rozwiązanie:

(Przede wszystkim upewnij się, że wygenerowałeś klucze, jak wyjaśniono na http://help.github.com/win-set-up-git/ )

utwórz plik ~ / .ssh / config (plik konfiguracyjny ssh znajduje się w katalogu użytkownika. W systemie Windows prawdopodobnie %USERPROFILE%\.ssh\config

Wklej w nim następujący kod:

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

Zapisz plik.

Wykonaj ssh jak zwykle:

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

Pamiętaj, że nie muszę podawać nazwy użytkownika ani numeru portu.

Kluczowe informacje są zapisane w odpowiedzi @ Sama, ale niezbyt istotne, więc wyjaśnijmy to jasno.

„Zły numer pliku” nie jest informacyjny, jest jedynie oznaką uruchomienia ssh git w systemie Windows.

Linia, która pojawia się nawet bez -vprzełącznika:

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

jest właściwie nieistotna .

Jeśli się na tym skupisz, stracisz czas, ponieważ nie jest to wskazówka na temat tego, na czym polega problem, a jedynie efekt uruchomienia ssh git w systemie Windows. Nie jest to nawet znak, że instalacja lub konfiguracja git lub ssh jest nieprawidłowa. Naprawdę, zignoruj ​​to .

To samo polecenie w systemie Linux wygenerowało zamiast tego tę wiadomość dla mnie, która dała rzeczywistą wskazówkę dotyczącą problemu:

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

Rzeczywiste rozwiązanie: zignoruj ​​„zły numer pliku” i uzyskaj więcej informacji

Skoncentruj się na dodawanych liniach za pomocą -vlinii poleceń. W moim przypadku było to:

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

Moim problemem była literówka w adresie IP, ale Twój może być inny.

Czy to pytanie dotyczy „złego numeru pliku”, czy wielu powodów, dla których połączenie może przekroczyć limit czasu?

Jeśli ktoś może udowodnić, że „zły numer pliku” pojawia się tylko wtedy, gdy rzeczywistą przyczyną jest „przekroczenie limitu czasu połączenia”, warto zastanowić się, dlaczego połączenie może przekroczyć limit czasu.

Do tego czasu „zły numer pliku” jest tylko ogólnym komunikatem o błędzie, a pełną odpowiedź na to pytanie można uzyskać, mówiąc „zignoruj ​​go i poszukaj innych komunikatów o błędach”.

EDYCJA: Qwertie wspomniał, że komunikat o błędzie jest rzeczywiście ogólny, ponieważ może się również zdarzyć w przypadku „Odmowa połączenia”. Potwierdza to analizę.

Proszę nie zaśmiecać tego pytania ogólnymi wskazówkami i odpowiedzią, nie mają one nic wspólnego z faktycznym tematem (i tytułem) tego pytania, czyli „Błąd Git SSH:„ Połącz z hostem: zły numer pliku ””. Jeśli korzystasz -vz bardziej pouczającej wiadomości, która zasługuje na własne pytanie, otwórz kolejne pytanie, a następnie możesz utworzyć do niego link.

To zadziałało dla mnie:

ssh -v [email protected] -p 443

Być może twoja zapora sieciowa lub aplikacja blokująca (PeerBlock itp.) Blokuje twój port

Możesz także spróbować:

telnet example.com 22

aby sprawdzić, czy masz łączność z serwerem. Widziałem tę wiadomość i okazało się, że VPN, na którym byłem, blokował dostęp. Odłączono od VPN i byłem gotowy.

Odkryłem, że dzieje się tak, gdy połączenie jest słabe. Miałem to kilka minut temu, kiedy pchałem do mojego repozytorium, ciągle zawodziło, a chwilę później połączenie zostało przerwane.

Po tym, jak wrócił, pchnięcie natychmiast przeszło.

Uważam, że może to być spowodowane spadkiem połączenia z Twojej lub ich strony.

Jeśli SSH jest zablokowane powyżej 22

po prostu zaktualizuj origindo https

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

sprawdź, czy wprowadzono zmiany

git remote -v

Po prostu miałem ten sam problem i próbowałem każdego rozwiązania, które mogłem znaleźć, ale żadne nie działało. Ostatecznie spróbowałem wyjść z Git Bash i ponownie go otworzyć i wszystko działało idealnie.

Więc spróbuj zamknąć Git Bash i ponownie go otworzyć.

Spróbuj zamknąć instancję git bash, za pośrednictwem której dokonałeś konfiguracji, i spróbuj ponownie. W końcu to zadziałało.

W systemie Windows próbowałem wyjść z git bash i uruchomić ponownie, ale nie zadziałało, w końcu ja (sfrustrowany) uruchomiłem ponownie i zadziałało następnym razem :)

Dokładnie sprawdź, czy opublikowałeś swoje klucze publiczne za pośrednictwem interfejsu administracyjnego GitHub.

Następnie upewnij się, że port 22 nie jest w jakiś sposób zablokowany (jak pokazano w tym pytaniu )

W moim przypadku zmienił się adres IP naszego hosta git.

Po prostu opróżnienie pamięci podręcznej DNS rozwiązało problem.

Utworzenie pliku konfiguracyjnego do korzystania z portu 443 nie zadziałało. W końcu spróbowałem wyłączyć połączenie Wi-Fi, włączyć je ponownie i problem zniknął. Dziwne. Głupie rozwiązanie, ale może komuś pomóc :)

Sprawdź pilota za pomocą git remote -v Coś jak ssh: /// gituser @ myhost: /git/dev.git

jest błędny z powodu potrójnego ukośnika ///

Widziałem ten problem podczas uzyskiwania dostępu do Bitbucket w sieci firmowej, podczas gdy git działa dobrze w sieci domowej.

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

Aby obejść ten problem, użyłem protokołu https.

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

Użyj odpowiednich słów, aby zastąpić „myaccount” i „myrepo”.

Poniższe rozwiązanie zadziałało, gdy próbowałem połączyć się przez SSH z wystąpieniem AWS EC2 Ubuntu z mojego komputera z systemem Windows 7 (32-bitowym) za korporacyjną zaporą ogniową, konfigurując serwer proxy.

Dodaj następujący blok do C:\Users\<YOUR_WINDOWS_USER>\.ssh\configpliku

> 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>

Będziesz musiał dodać podobną konfigurację dla każdego hosta, do którego chcesz SSH.

Miałem problem, gdy miałem otwarte połączenie FileZilla w systemie Windows. Zamknięta FileZilla -> Problem rozwiązany.

Jest to proste rozwiązanie pozwalające zaoszczędzić trochę pisania. Możesz łatwo wykonać następujące kroki w git bash.

(1) utwórz zdalne repozytorium

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

Uwaga: jeśli Twoje hasło zawiera znak „@”, użyj zamiast tego „% 40”

(2) Następnie zrób co chcesz ze zdalnym repozytorium

ex:- git push origin master

W moim przypadku pomogło po prostu ponowne uruchomienie routera WiFi.