After having this problem myself, I found a solution that works for me:
Error message:
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
You will only see the bad file number message when on windows using the MINGGW shell. Linux users will just get Timed out.
Problem:
SSH is probably blocked on port 22. You can see this by typing
$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
As you can see the state is Filtered, which means something is blocking it. You can solve this by performing an SSH to port 443 (your firewall / isp will not block this). It is also important that you need to ssh to "ssh.github.com" instead of github.com. Otherwise, you will report to the webserver instead of the ssh server. Below are all the steps needed to solve this problem.
Solution:
(First of all make sure you generated your keys like explained on http://help.github.com/win-set-up-git/)
create file ~/.ssh/config (ssh config file located in your user directory.
On windows probably %USERPROFILE%\.ssh\config
Paste the following code in it:
Host github.com
User git
Hostname ssh.github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa
Port 443
Save the file.
Perform ssh like usual:
$ssh -T github.com
$Enter passphrase for key '.......... (you can smile now :))
Note that I do not have to supply the username or port number.
The key information is written in @Sam's answer but not really salient, so let's make it clear.
The line which appears even without -v
switch:
ssh: connect to host (some host or IP address) port 22: Bad file number
is actually irrelevant.
If you focus on it you'll waste your time as it is not a hint about what the actual problem is, just an effect of running git's ssh on Windows. It's not even a sign that the git or ssh install or configuration is wrong. Really, ignore it.
The very same command on Linux produced instead this message for me, which gave an actual hint about the problem:
ssh: connect to host (some host or IP address) port 22: Connection timed out
Focus on lines being added with -v
on command line. In my case it was:
debug1: connect to address (some host or IP address) port 22: Attempt to connect timed out without establishing a connection
My problem was a typo in the IP address, but yours may be different.
If someone can prove that "bad file number" only appears when the actual reason is "connection time out" then it makes some sense to address why connection could time out.
Until that, "bad file number" is only a generic error message and this question is fully answered by saying "ignore it and look for other error messages".
EDIT: Qwertie mentioned that the error message is indeed generic, as it can happen on "Connection refused" also. This confirms the analysis.
Please don't clutter this question with general hints and answer, they have nothing to do with the actual topic (and title) of this question which is "Git SSH error: “Connect to host: Bad file number”". If using -v
you have more informative message that deserve their own question, then open another question, then you can make a link to it.
This worked for me:
ssh -v [email protected] -p 443
Maybe your firewall or a blocker application (PeerBlock etc.) is blocking your port
You can also try to:
telnet example.com 22
to see if you have connectivity to the server. I saw this message and it ended up being the VPN I was on was blocking access. Disconnected from the VPN and I was good to go.
What I found is that, this happens when your connection is poor. I had it a few minutes ago when pushing to my repo, it kept failing and a while after that, the connection went down.
After it came back up, the push immediately went through.
I believe it can be caused by either a drop in connection from either your side or theirs.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With