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


153

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

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


Mam to dzisiaj. Wygląda na to, że Github nie działa.
ysrb

TL; DR: Ignoruj ​​„zły numer pliku”. Informacji, których szukasz, nie ma w tej wiadomości. To może oznaczać wszystko. Szczegóły na stackoverflow.com/a/22788046
Stéphane Gourichon

Odpowiedzi:


186

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

Komunikat o błędzie:

    ssh -v git@github.com
    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.


4
Innymi słowy, ustanawiasz połączenia SSH przez port HTTPS .
Enrico Campidoglio

1
Nie rozumiem w „Wklej w nim następujący kod:”. Jak mam rozwiązać problem z błędnym numerem pliku? Czy powinienem go utworzyć i zapisać jako plik notatnika?
David Dimalanta,

27
Zamiast tego dostajęssh: connect to host ssh.github.com port 443: Bad file number
cqcn1991

Działa to również w przypadku bitbucket.org, kiedy moja poprzednio działająca konfiguracja nagle przestała działać. Najlepsze jest to, że jedyne, co musiałem zrobić, to wprowadzić zmiany w pliku konfiguracyjnym SSH.
Kevin Condon,

2
Używając .ssh/configpliku w systemie Windows 7, upewnij się, że masz User-Enviromental Var HOMEz %USERPROFILE%wartością -> pomogło mi, kiedy mój ssh nie mógł go znaleźć
Jook

40

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.


1
Tak, dodanie -v do mojego scpwiersza poleceń dodało „debug1: połącz się z adresem 216.34.181.70 port 22: Odmowa połączenia” przed „Zły numer pliku”, więc nie zawsze jest to błąd „przekroczony limit czasu”.
Qwertie,

Och, Windows zawsze pokazuje niejasne komunikaty o błędach, nawet gdy narzędzie jest tradycyjnie używany na Linuksa i innych systemów UNIX-like ...
lilydjwg



5

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.


4

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.


1
Ten błąd pojawia się również podczas korzystania z mojego Verizon Jetpack, który wydaje się przerywać połączenie, gdy używam ssh z dwóch oddzielnych urządzeń. Więc coś w Jetpacku zrywa połączenie i bad file numberpojawia się błąd, gdy połączenie znika.
cod3monk3y

1
Ten błąd pojawia się podczas korzystania z połączenia hotspot telefonu z laptopem.
Lucas Morgan

@LucasMorgan to samo tutaj. Tego właśnie używałem, kiedy to się stało.
cudowny mróz

3

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


poprawnie, jednak będziesz musiał to zrobić dla każdego repozytorium za pomocą tej metody. W pliku konfiguracyjnym jest stosowany globalnie.
Sam,

2

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


2

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.


10
„w końcu dla mnie zadziałało” sprawia, że ​​myślę, że mogłeś robić inne rzeczy w tym procesie, które mogły mieć swój udział.
Jake Berger

1

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


1

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 )


1
>> Najpierw upewnij się, że „git” to nazwa Twojego konta użytkownika GitHub. Jak opisano w przewodniku po git: Przetestuj wszystko. Aby upewnić się, że wszystko działa, przejdź teraz przez SSH do GitHub. Nie zmieniaj części „git@github.com”. To powinno tam być. >> Następnie upewnij się, że port 22 nie jest w jakiś sposób zablokowany -> Wyłączyłem zaporę systemu Windows XP, ale nic się nie zmieniło.
Massimo Ugues

1

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

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


0

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


0

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

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


0

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://myaccount@bitbucket.org/myaccount/myrepo.git
Password for 'https://myaccount@bitbucket.org':

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


0

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.


-1

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


-1

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

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.