Github - unexpected disconnect while reading sideband packet

It might be your network issue. If the network is too slow, then it might disconnect the connection unexpectedly.

If you have good internet and are still getting this message, then it might be an issue with your post buffer. Use this command to increase it (for example) to 150 MiB:

git config --global http.postBuffer 157286400 

According to git-config Documentation for http.postBuffer:

Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.

Note that raising this limit is only effective for disabling chunked transfer encoding and therefore should be used only where the remote server or a proxy only supports HTTP/1.0 or is noncompliant with the HTTP standard. Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.

So this is only a mitigation in cases where the server is having issues. This is most likely not going to fix push problems to GitHub or GitLab.com.

None of the above worked for me, git config --global pack.window 1 did.

For what this does, see https://git-scm.com/docs/git-pack-objects in particular the --window argument:

"The objects are first internally sorted by type, size and optionally names and compared against the other objects within --window to see if using delta compression saves space."

So setting the window to 1 effectively disables delta compression (delta compression means only differences between objects are stored to save space when pushing commits)

git config --global http.version HTTP/1.1

solved the problem for me. I was unable to push large commits in multiple different github repositories earlier.

I had the same problem. I have a repo with 20000 files, the whole repo is about 5 GB in size, and some files are 10 MB in size. I could commit to the repo without problems and I could clone without problems (it took a while, though). Yet, every other time I pulled this repo to my machine I got

remote: Enumerating objects: 1359, done. remote: Counting objects: 100% (1359/1359), done. remote: Compressing objects: 100% (691/691), done. remote: Total 1221 (delta 530), reused 1221 (delta 530), pack-reused 0 fetch-pack: unexpected disconnect while reading sideband packet fatal: early EOF fatal: fetch-pack: invalid index-pack output 

What finally helped was this tip. Go to your user directory and edit .git/config and add:

[core] packedGitLimit = 512m packedGitWindowSize = 512m [pack] deltaCacheSize = 2047m packSizeLimit = 2047m windowMemory = 2047m 

Voilá. No more errors.

None of the above worked for me. But this is worked for me:

Let's try to resolve the issue by increasing buffer:

git config --global http.postBuffer 52428800 

Turn off the compression

git config --global core.compression 0 

Try the workaround here:

$ git clone --depth 1 https://innersource.%2A.com/*repoName.git $ cd repository $ git fetch --unshallow 

Connection, VPN, Antivirus, Firewall

Most probable reason. Especially if your git is up to date (if not you can update it).

The first thing to try is to check your connection and that it is stable.

My connection is excellent ===> wait Are you using VPN ?

=> Disable it. And try. (VPN's are big culprit for such a problem)

Still doesn't work? ==> Check for antivirus and firewalls.

• Internet stable.
  
• VPN VPN VPN => Big culprit
• firewall and antivirus
• git up to date

If that doesn’t work see the below:

VPN dynamic IP rotation is the culprit

• If all works well after disabling the VPN. If you still need to use the VPN. Try to use a static IP instead. As mainly it makes a lot of sense. It's working working. Then bghghgh. It's VPN IP rotation with dynamic IP issue. (If you switch to static and it works for you. Please drop a comment. To sustain that statically.)

• Experiment I led

  • Cloned [email protected]:microsoft/vscode.git repo with a VPN with a static IP, cloning at 100kib/s overage (took 2 hrs cloning +).
    • This repo is so large. It fails to clone if a VPN with a dynamic IP is used.
    • Result - Works fine with a VPN with static IP ✅

Git cache, buffers and memory

https://stackoverflow.com/a/29355320/7668448

Open git global config:

git config --global -e 

And add those entries:

[core] packedGitLimit = 512m packedGitWindowSize = 512m [pack] deltaCacheSize = 2047m packSizeLimit = 2047m windowMemory = 2047m 

Try to clone again.

If that doesn't work! =>

You can try the partial fetch method and disabling compression:

https://stackoverflow.com/a/22317479/7668448

One command at a time

git config --global core.compression 0 git clone --depth 1 <repo_URI> git fetch --unshallow 

More details are on the link.

If you are using SSH URLs, you can try the following, it worked for me the two times I had the same issue:

1. Switch to HTTPS origin URL: git remote set-url origin https://github.com/<your_repo>
2. Do the push. It should not fail now.
3. Switch back to SSH: git remote set-url origin [email protected]:<your_repo>

I'm still not sure what is the cause of the issue. This is just a work around.

On Windows 11, I solved this problem by upgrading build-in OpenSSH which is in C:\Windows\System32\OpenSSH folder.

You can download the latest binaries here: https://github.com/PowerShell/Win32-OpenSSH/releases

See #2012 in the release notes which solves the problem:

v9.2.2.0p1-Beta Latest This is a beta-release (non-production ready) This release includes: Security Fixes: Upgrade to LibreSSL 3.7.2. Please refer to https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.7.2-relnotes.txt MSI: change inbound firewall rule that opens port 22 to apply to Private networks only Non-Security Fixes: Add U2F/Fido2 keys to the agent from other clients: #1961 - thanks @ddrown! Fix output codepage after executing scp/sftp/ssh/ssh-keygen command: #2027 - thanks @kemaruya! Fix early EOF termination when running git fetch over ssh: #2012 - thanks @cwgreene! Revert mark-of-the-web for SCP/SFTP file downloads: #2029 

I didn't want to believe it but after 3 failed clones, switching from a wifi connection (on Mac) to hardwired connection (on Linux) made it work first time. Not sure why!

https://serverfault.com/questions/1056419/git-wsl2-ssh-unexpected-disconnect-while-reading-sideband-packet/1060187#1060187

Whatever you need:

 git config --global http.postBuffer 524288000 # Set a larger buffer size git config --global core.compression 0 # Disable compression 

In my case, I had a few files that were over 100MB in size when trying to push my initial commit. Since GitHub apparently doesn't allow this, you get an error "unexpected disconnect while reading sideband packet fatal: the remote end hung up unexpectedly".

Using git rm was not enough, I had to start all over again with git init, git add, git commit and git push to resolve the issue.

This is a problem sending bits over https protocol. You can configure git to use ssh instead.

First create an ssh-key on your workstation, then copy that key to Github to authenticate your computer without a password. Then configure git to use ssh protocol instead of https.

Create ssh key

No need to repeat Github's excellent instructions here.

Simple way

Use git protocol for the clone command:

git clone [email protected]:repo-name 

General method: Configure git to use ssh (git) protocol instead of https

This option is good if you are using GitHub Desktop and don't have direct control over the clone URL.

git config --global url."[email protected]:".insteadOf "https://github.com/" 

For Github enterprise, make your local translations for your instance rather than public github.

After this, you should be able clone without this error.

There's a known issue in Git for Windows version 2.47.0.windows.1 that can lead to this error, and it can be resolved by installing a different version:

https://github.com/git-for-windows/git/issues/5199

For windows

set GIT_TRACE_PACKET=1 set GIT_TRACE=1 set GIT_CURL_VERBOSE=1 git init 

and then clone the project you need it worked for me

All options above didn't solve the issue for me. I noticed that some helped and went past the initial limit, but still stopped halfway.

My issue was that, I was not able to fetch/clone/pull my repos due to some large files in the commit history that exceeded the 100mb mark. Also my slow internet made it impossible to fetch bad repos that still had those commit history to resolve the problem locally before pushing online.

Based on some of the comments that focused on the issue being a network/internet problem, I decided to focus on my SSH config and improve it for performance to see if it could help solve the problem. And Viola!!! Problem solved. I still maintained some of the configurations from previous suggestions, expecially the one related to the .git/config cache settings

[core] packedGitLimit = 512m packedGitWindowSize = 512m [pack] deltaCacheSize = 2047m packSizeLimit = 2047m windowMemory = 2047m 

This is how I updated by SSH confi at .ssh/config :

To improve Git download speed Linux, you can modify the SSH client configuration to optimize the SSH connection. Here are a few configuration options you can consider:

Use a faster SSH algorithm: By default, OpenSSH prioritizes the ssh-rsa algorithm for SSH connections. However, the ecdsa-sha2-nistp256 algorithm is generally faster. You can add the following line to your ~/.ssh/config file to use it:

Host * HostKeyAlgorithms ecdsa-sha2-nistp256,ssh-rsa 

Enable connection multiplexing: SSH connection multiplexing allows reusing existing SSH connections, which can significantly reduce the overhead of establishing new connections. Add the following lines to your ~/.ssh/config file to enable connection multiplexing:

 Host * ControlMaster auto ControlPath ~/.ssh/control:%h:%p:%r ControlPersist yes 

Increase SSH connection timeout: In case you have a slow or unstable network, increasing the SSH connection timeout can prevent premature connection terminations. Add the following line to your ~/.ssh/config file to increase the timeout to 60 seconds:

Host * ServerAliveInterval 60 

Use a faster cipher: You can try using a faster cipher algorithm to improve SSH performance. However, keep in mind that it may require the remote SSH server to support the chosen cipher. For example, to use the [email protected] cipher, add the following line to your ~/.ssh/config file:

Host * Ciphers [email protected] 

After making any changes to the SSH client configuration, save the file and try using Git again to see if there is an improvement in download speed.

After assessing all, I combined them and put this at the end of my .ssh/config file:

Host * HostKeyAlgorithms ecdsa-sha2-nistp256,ssh-rsa ControlMaster auto ControlPath ~/.ssh/control:%h:%p:%r ControlPersist yes ServerAliveInterval 60 Ciphers [email protected] 

Remember to exercise caution and be mindful of security implications when modifying SSH configuration options. Some options may require compatibility with the remote SSH server and its configuration.

I tried many of the suggestions above, but none worked. I finally upgraded my git client from 2.37 to 2.41 & the problem went away.

Note, I've been getting random "your connection was interrupted" so my PC seems to have issues, which is another story.

First, turn off compression:

git config --global core.compression 0 

Next, let's do a partial clone to truncate the amount of info coming down:

git clone --depth 1 <repo_URI> 

When that works, go into the new directory and retrieve the rest of the clone:

git fetch --unshallow 

or, alternately,

git fetch --depth=2147483647 

Now, do a regular pull:

git pull --all 

In my case I got this error with the first commit to a new repo.

I just deleted the .git folder and then added a few files at a time, committing with each addition.

I managed to add everything back, without running into the same error.

You may have many commits, and buried in your commits are files that are too big for GitHub to upload. If so, you may see this sidepacket error, rather than the usual recommendation to use Git LFS.

The solution for me was to remove the large files.

I beleive you send your projects via https, not ssh. Try to use

ssh://git@host:port/path/name.git 

Check if ssl verification in .gitgonfig is turned on

sslVerify = true 

If you do not have SSH keys, generate them and add to your remote. Here example for BitBucket:

1. https://confluence.atlassian.com/bitbucketserver076/creating-ssh-keys-1026534841.html
2. https://confluence.atlassian.com/bitbucketserver076/ssh-user-keys-for-personal-use-1026534846.html

Accept key during connection

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes 

I tried the suggestions above, without success.

It turns out my issue was path length. I don't know if it was the number of nested directories (which are plentiful) or overall path length (path + file).

I cloned at the root of my drive and it worked (yes, on Windows 10).

UPDATE: To clarify, I had to clone to the root of my drive, using the accepted answer.

Try pushing from your Vscode's git GUI. It worked for me.

For me, a quick restart of my router solved the problem. No other configuration changes were needed, but situations may vary.

Nothing of the above worked, but switching from OpenSSH to plink did work:

$env:GIT_SSH="C:\ProgramData\chocolatey\bin\PLINK.EXE"

My setup is:

• C:\windows\System32\OpenSSH\ssh.exe (8.1.0.1)
• C:\Program Files\Git\cmd\git.exe (2.37.3.1)
• Microsoft Windows [Version 10.0.19044.2604]

I have faced the similar issue and solved by using setting the remote url as SSH one.

git remote set-url origin <SSH URL> 

My repo was cloned initially with SSH and then changed to HTTPS caused the problem for me. So, I have set again the remote origin as SSH and it starts working as usual.

Adding to a previous solution, what solved the issue for me was to disable jumbo frames on my network, in addition to the mentioned config value.

I have no idea if the problem was my ISP or local (or maybe even Github), but it doesn't hurt to try for whoever reads this.

None of these options worked for me on Windows when doing the git fetch --unshallow. To correct my instance, I went into the directory and ran git gui to bring up the UI version on Windows. Then I selected .

This completed without error, and I was then able to do the git fetch --unshallow with and without compression.

I tried everything above and nothing worked.

So I created a new repository using Github Desktop (opened as admin) on Windows 11, and I copied all my files from the faulty repo into the new one via the normal file explorer operations. I pushed the new changes to Github (remote) still using the Github desktop app. I then opened the local repo in VScode. I am now using the new repo and everything is fine. I can now push to git successfully after making edits.

I got this problem today out of nowhere — the same repo was working the day before with no problems. I solved it by deleting my SSH key on the Github config panel and adding it again, as described in Github docs. I did not need to create new SSH keys.