Resolving Git SSH Error: "Bad file number" When Connecting to GitHub: Port Blocking and Configuration Adjustment

Dec 03, 2025 · Programming · 31 views · 7.8

Keywords: Git | SSH | GitHub | Port Blocking | Windows Configuration

Abstract: This article provides an in-depth analysis of the "Bad file number" error that occurs during Git SSH connections to GitHub, commonly seen on Windows systems due to port 22 being blocked by firewalls or ISPs. Based on a high-scoring Stack Overflow answer, it offers a detailed solution: modifying the SSH configuration file to switch the connection port from 22 to 443 and adjusting the hostname to ssh.github.com to bypass the blockage. The article also explains the misleading nature of the error message, emphasizing the importance of focusing on more specific debug outputs like connection timeouts. It includes problem diagnosis, configuration steps, code examples, and verification methods, targeting developers using Git and SSH, particularly on Windows.

Problem Background and Error Analysis

When using Git for version control, connecting to remote repositories like GitHub via the SSH protocol is a common practice. However, users may encounter connection failures, with error messages such as ssh: connect to host github.com port 22: Bad file number on Windows environments. This error message itself does not directly indicate the root cause but is a generic output from SSH on Windows platforms. According to the best answer in the Q&A data (score 10.0), the core issue typically involves port 22 being blocked by firewalls or Internet Service Providers (ISPs), leading to connection timeouts.

Running the SSH command in debug mode (using the -v parameter) reveals more detailed output, e.g., debug1: connect to address 207.97.227.239 port 22: Attempt to connect timed out without establishing a connection. This suggests that the connection attempt timed out on port 22 without establishing a link. Scanning GitHub's port 22 with tools like nmap may show a state of "filtered," further confirming the blockage. Therefore, the key to resolving this issue lies in bypassing the blockage on port 22.

Solution: Modify SSH Configuration to Use Port 443

GitHub supports SSH connections via port 443, which is commonly used for HTTPS traffic and is less likely to be blocked by firewalls or ISPs. The solution involves modifying the user's SSH configuration file (~/.ssh/config) to adjust connection parameters. Below are the steps refined from the best answer:

  1. Ensure SSH Keys Are Generated: First, confirm that SSH key pairs (public and private keys) have been generated according to GitHub's official guide, and the public key is added to the GitHub account. This can be done by running the ssh-keygen command, with specific steps available in GitHub documentation.
  2. Create or Edit the SSH Configuration File: In the .ssh folder under the user's home directory, create or edit the config file. On Windows systems, the path is typically %USERPROFILE%\.ssh\config. If the file does not exist, create it manually.
  3. Add Configuration Content: Paste the following configuration code into the config file. This configuration specifies using port 443 for connections and sets the hostname to ssh.github.com to ensure requests are routed correctly to the SSH server rather than the web server.
    Host github.com
        User git
        Hostname ssh.github.com
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa
        Port 443
    Note: The IdentityFile path should be adjusted based on the actual key location, e.g., C:\Users\username\.ssh\id_rsa on Windows. PreferredAuthentications publickey ensures public key authentication, and Port 443 is the critical modification.
  4. Save and Test the Connection: After saving the configuration file, run an SSH test command to verify the connection. Use ssh -T github.com, which will attempt to connect and return authentication status. If configured correctly, the system will prompt for the key passphrase (if set) and then display a success message, such as Hi username! You've successfully authenticated, but GitHub does not provide shell access..

This method avoids using port 22 directly, thereby bypassing potential blockages. According to the Q&A data, other answers (score 2.1) supplement that the "Bad file number" error is misleading on Windows and should be ignored in favor of more specific debug information like connection timeouts. This highlights the importance of using the -v parameter for detailed output during troubleshooting.

Code Examples and In-Depth Explanation

To illustrate the configuration process more clearly, here is a complete example demonstrating the journey from error diagnosis to successful connection. Assume the user is on Windows using Git Bash or a similar terminal.

First, run the initial SSH command to reproduce the error:

$ ssh -v git@github.com
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /c/Users/username/.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

Here, the debug1 line shows the connection timing out on port 22, while "Bad file number" is a generic error on Windows. Next, use nmap to scan port 22 (if available):

$ nmap -sS github.com -p 22
Starting Nmap 5.35DC1 ( http://nmap.org ) at 2023-10-01 10:00 UTC
Nmap scan report for github.com (207.97.227.239)
Host is up (0.10s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh

The "filtered" state confirms port blockage. Then, create the SSH configuration file. In the terminal, use a text editor or command line to create the file:

$ nano ~/.ssh/config

Paste the configuration content and save. Afterward, test the new configuration:

$ ssh -T github.com
Enter passphrase for key '/c/Users/username/.ssh/id_rsa':
Hi username! You've successfully authenticated, but GitHub does not provide shell access.

This indicates a successful connection. If issues arise, check the configuration file syntax or key permissions (e.g., ensure private key file permissions are set to 600).

Summary and Best Practices

Resolving the "Bad file number" error in Git SSH connections centers on identifying port blockage and adjusting configuration to use an alternative port. This article, based on a high-scoring answer, provides a comprehensive guide from diagnosis to resolution. Key points include: ignoring the misleading "Bad file number" message on Windows and focusing on specific errors like connection timeouts; modifying the SSH configuration file to use port 443 and ssh.github.com hostname; and verifying the connection with test commands.

Additionally, it is recommended that users always use the -v parameter for detailed output when encountering SSH issues, as this aids in quick problem localization. For other platforms like Linux, error messages may differ (e.g., directly showing "Connection timed out"), but the solution is similar. Maintaining SSH key security and updating Git to the latest version are also good practices. By following the steps in this article, developers should effectively resolve connection problems, ensuring smooth Git operations.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.