Git Remote: Error: fatal: protocol error: invalid character string length: Unab

Question

I set up a git server and now I want to first upload my repo from the client. I used git push origin master and got this error message:

 fatal: protocol error: bad line length character: Unab 

I do not know what happened. I do not know what "Unab" is. I tried resizing the shell, but it still remains “Unab”. I can not find a solution for this error message.

I am setting up a server using "authorized_keys" and SSH. (I can connect to it using SSH.)

Seems to be a git problem?

BTW: the server is configured on a Windows 7 virtual machine

Answer 1

This error message is a little dumb, but what it is actually trying to tell you is that the remote server did not respond with a proper git response. Ultimately, a problem arose on the server running the git-receive-pack process.

In git protocol, the first four bytes must be the length of the string. Instead, they were Unab characters ... which is probably the beginning of the error message. (i.e. probably " Unable to... " do something).

What happens when running ssh <host> git-receive-pack <path-to-git-repository> ? You should see an error message that your git client is on, and you can fix it.

Answer 2

I had a similar problem but the exact error message:

fatal: protocol error: string length character: Usin

This is on Windows, with the path plink.exe PuTTY installed with GIT_SSH .

Possible problems and solutions:

• Make sure the path to plink.exe correct. Unix style style also works fine, e.g. /c/work/tools/PuTTY/plink.exe
• Verify that the key agent PuTTY ( pageant.exe ) is running
• Verify that the key agent contains a valid key to access the server.

Answer 3

Perhaps you have a statement on the .bashrc server that produces the output. For example, I had this:

 [[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" rvm use ruby-1.9.3-p194@rails32 

In this case, the output from using rvm will be (erroneously) interpreted as coming from git. Therefore replace it with:

 rvm use ruby-1.9.3-p194@rails32 > /dev/null 

Answer 4

I had the same problem after installing GIT on Windows. At first it worked; then, the next day (after rebooting the PC), this was no longer there, and I received the following:

 $ git pull fatal: protocol error: bad line length character: git@ 

The problem was that after the restart, the automatically launched Putty "pageant.exe" no longer had an active key. When you add a key to a contest, this is not a permanent parameter by default. I just had to add the key again, and it worked fine. Thus, for this case, it is necessary to automatically download the download key, as described here:

https://www.digitalocean.com/community/tutorials/how-to-use-pageant-to-streamline-ssh-key-authentication-with-putty

Answer 5

For GitExtension users:

I encountered the same problem after updating git to 2.19.0

Decision:

Tools> Settings> Git Extensions> SSH

Select [ OpenSSH ] instead of [ PuTTY ]

Answer 6

After loading the SSH private key in the Git extensions, this problem will be resolved.

Answer 7

You can redirect any output from .bashrc to stderr :

 # inside .bashrc echo 'some error/warning/remind message' 1>&2 

git will ignore these characters

Answer 8

I had a similar problem with Windows using Git Bash. I kept getting this error while trying to make a git clone. The repository was in a Linux box with GitLab installed.

 git clone git@servername:path/to/repo fatal: protocol error: bad line length character: git@ 

I made sure that the ssh key was generated. The public key has been added to GitLab. The ssh agent is running and the generated key has been added ( github link ).

I ran out of options, and then finally tried to close Git Bash and reopen it by right-clicking Run as Administrator. Worked after that.

Answer 9

It might help someone. When I tried to clone the project from an EC2 instance, I received the following error:

 Cloning into 'repo1'... fatal: protocol error: bad line length character: logi 

Permission for me includes the following steps:

• Verify that the SSH key (public) has been added / updated in the EC2 instance.
• Make sure that the authentication agent (in my case its Pageant = Putty Authentication Agent) is running and the corresponding private key is loaded.

• Use EC2 SSH key key for public key to clone git. Example:

  git clone ssh: // {SSH key ID} @ someaccount.amazonaws.com / v1 / repos / repo1

Answer 10

Check your startup files in the account used to connect to the remote computer for echo operators. For the Bash shell, these will be your .bashrc and .bash_profile, etc. Edward Thomson is right in his answer, but the specific problem I experienced is when there is a printout of the boiler plate when entering the server via ssh. Git will receive the first four bytes of this boiler plate and raise this error. Now in this particular case, I'm going to assume that “Unab” is actually “Unable ...”, which probably indicates that there is something else wrong with the Git host.

Answer 11

For me it was because I recently added

 RequestTTY force 

in .ssh / config

commenting on this allowed him to work

Answer 12

In my case, after receiving it was written: fatal: protocol error: bad line length character: Pass . Also after clicking I got: fatal: protocol error: bad line length character: git@Done .

After restarting Windows, I had to run the "PuTTY agent" (pageant.exe) again and add the private key, which disappeared from the list of keys.

Answer 13

In my case, the problem was 32-bit Putty and pageant.exe - it cannot interact with 64-bit TortoisePlink.exe. Replacing the 32-bit Putty with the 64-bit version solved the problem.

Answer 14

I had the same error "fatal: protocol error: bad line length character: shmi" Where shmi is the username in my case. I switched SSH from PuTTY to OpenSSH in "Git Extensions->Settings->SSH" . That helped.

Answer 15

I had the same problem as Christer Fernstrom. In my case, this message that I put in my .bashrc, which reminds me, makes a backup when I did not do this after a couple of days.

Answer 16

For someone, the following may help: When I tried to clone a project on my AWS EC2 instance, I received the following error:

 Cloning into 'AWSbareRepo'... fatal: protocol error: bad line length character: Plea 

This was caused by trying ssh as root instead of EC2-USER. if you are actually ssh without making a git clone ... you will see an error message in the line "Please log in with ec2-user", As soon as I made a git clone as ec2-user, that was good.

Answer 17

I also encounter this error from time to time, but when this happens it means my branch is not updated, so I need to do git pull origin <current_branch>

Answer 18

FYI I got the same error message after I upgraded the CentOS6 container to CentOS7 - some git operations started to fail when creating the container, for example.

 # git remote show origin fatal: protocol error: bad line length character: Inva 

Running ssh gave me an error that I could find:

 # ssh [e-mail] Invalid clock_id for clock_gettime: 7 

This led me to https://github.com/wolfcw/libfaketime/issues/63 , where I realized that I forgot that I had LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 in the parent file Docker. Commenting on this, the bug is fixed.

Answer 19

Git does not ask for a password and does not work with a similar cryptic message "fatal: protocol error: string length character: user" if you do not have an authentication setting using a private key , as good.

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server tells how to specify the public key on the server. Basically add the public key to ~ / .ssh / authorized_keys or ~ / .ssh / authorized_keys2

I had to work a bit on how to provide a secret Git Bash key on a Windows machine. Dan McClain's answer at https://serverfault.com/questions/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 describes this. In addition to his answer, in my case, the private key file should have been called id_rsa.pub

Answer 20

For me, the same host content in Putty worked with the private key (convert with puttygen). Any git bash commands after this have no problems.

Answer 21

If you are using Putty. Then make sure Pageant is running and your private key is loaded in Pageant (right-click the Pageant icon on the taskbar and select "View Keys" from the menu that appears).

Otherwise, when you do in cmd.exe:

git clone ssh://name@host: /path/to/git/repo.git

you will get this message "fatal: protocol error: invalid character length string:"

Answer 22

Error converted to: fatal: protocol error: invalid string length character: fata p>

after adding the git -upload-pack location to the system path.

The problem seems to be related to the apostrophe around the repository name: "Search with a tool like Process Monitor" (from sys internal systems), which was added by the git client. This seems to be a problem with git specific windows.

I tried the same command line at the server prompt: the complete error was "fatal: not a given repository (or any of the parent directories): git"

In conclusion, for me it seems like a software bug. Keep in mind that I am not a git expert, this is the first time I use git, I came from subversion and persistently.

Answer 23

We came across this as well.

 Counting objects: 85, done. Delta compression using up to 4 threads. Compressing objects: 100% (38/38), done. Writing objects: 100% (38/38), 3.38 KiB | 0 bytes/s, done. Total 38 (delta 33), reused 0 (delta 0) Auto packing the repository for optimum performance. fatal: protocol error: bad line length character: Remo error: error in sideband demultiplexer 

I don’t know the details of what went wrong, but in our case it caused the disk on the server to be full.

Answer 24

It can be access to security on your computer, are you running Pageant (which is a putty agent)?

Answer 25

you can always have an http link with your git project. You can use this instead of the ssh link. This is just the option you have.

Answer 26

Well, I had the same problem (Windows 7). Try to get a password repo. I am using Git Bash + Plink (GIT_SSH environment variable) + Pageant. Removing GIT_SSH (temporary) helps me. I don’t know why I can’t use the login by logging in and entering RSA at the same time ...

Answer 27

The late answer is here, but hope this helps someone. If this is a protocol error, it must do something with local git, which cannot communicate with remote git. This can happen if you cloned the repo through ssh and after some time you lost the repo keys, or your ssh agent can no longer find these keys.

Decision

• Create a new key and add it to the git repository or configure your ssh agent to download the keys if you still have the keys with you and not with someone else;)

• Another quick solution is to go to the .git directory and edit the config [remote "origin"] url file from git to http so that the ssh keys are not needed for pressing and it will return to asking for your username and password.

   [remote "origin"] url = git@gitlab.*****.com:****/****.git fetch = +refs/heads/*:refs/remotes/origin/* 

Change to

  [remote "origin"] url = http://gitlab.*****.com/****/****.git fetch = +refs/heads/*:refs/remotes/origin/* 

Answer 28

Changing ssh exectuable from builtin to nativ in settings / version control / git did the trick for me.

Answer 29

TL; DR: don't omit username@ in your remote urls when on Windows.

On Linux and on Windows with ssh by default, you can omit the username from remote URLs, like this:

 git clone server-name:/srv/git/repo-name 

Because the standard behavior of ssh is to use any username you are currently logged into. If you are running Windows and have configured git to use plink.exe so that you can use the key loaded in your pageant , this will not work because plink does not have the same automatic username behavior, which leads to such a cryptic message error, because that he will request a username:

 $ plink server-name login as: _ 

Against:

 $ plink username@server-name ...logs you in... 

If you have already cloned the repository in any way, you can fix the remotes in your .git/config by adding username@ to the remote URL.

Answer 30

Check if Shell access is allowed on the server.