Git Remote: Error: fatal: protocol error: bad line length character: Unab

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

fatal: protocol error: bad line length character: Unab

I don’t know what’s wrong. I don’t know what “Unab” is. I tried to resize the shell but it is still “Unab”.
I cannot find a solution for this error message.

I setup the server with “authorized_keys” and SSH. (I can connect to it, using SSH.)

It seems to be a git problem?

BTW: The server is set up in a Windows 7 VM

  • Netbeans, git, reject hostKey?
  • Multiple GitHub Accounts & SSH Config
  • Git bash can't access home directory on fresh machine
  • Issue with cloning git repository
  • Create a Git Repo through SSH and Cloning it Locally
  • What are the supported git url formats?
  • Permission denied (publickey) errors on Windows when using Moovweb
  • “Access denied” when pushing to remote repository via SSH
  • 23 Solutions collect form web for “Git Remote: Error: fatal: protocol error: bad line length character: Unab”

    This error message is a bit obtuse, but what it’s actually trying to tell you is that the remote server didn’t reply with a proper git response. Ultimately, there was a problem on the server running the git-receive-pack process.

    In the Git protocol, the first four bytes should be the line length. Instead, they were the characters Unab… which is probably the beginning an error message of some kind. (ie, it’s probably “Unable to...” do something).

    What happens when you run ssh <host> git-receive-pack <path-to-git-repository>? You should see the error message that your git client is barfing on and you may be able to correct it.

    I had similar issue, but the exact error message was:

    fatal: protocol error: bad line length character: Usin

    This is in Windows, with GIT_SSH set to the path of plink.exe of PuTTY.

    Possible problems and solutions:

    • Make sure the path to plink.exe is correct. Unix style path works fine too, for example /c/work/tools/PuTTY/plink.exe
    • Make sure the key agent of PuTTY (pageant.exe) is running
    • Make sure the key agent contains a valid key to access the server

    Maybe you have a statement in the server’s .bashrc that produces output. I, for example 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 the rvm use will be (wrongly) interpreted as coming from git. So replace it by:

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

    You can redirect any output from .bashrc to stderr:

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

    git will ignore this symbols

    After loading the SSH private key in Git Extensions, this issue gets resolved.

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

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

    I made sure the ssh key was generated. The public key was added on GitLab. The ssh-agent was running and the generated key was added (github link).

    I ran out of options and then finally tried closing Git Bash and opening it again by right clicking ‘Run as Administrator’. Worked after that.

    Check your startup files on the account used to connect to the remote machine for “echo” statements. For the Bash shell these would be your .bashrc and .bash_profile etc. Edward Thomson is correct in his answer but a specific issue that I have experienced is when there is some boiler-plate printout upon login to a server via ssh. Git will get the first four bytes of that boiler-plate and raise this error. Now in this specific case I’m going to guess that “Unab” is actually the work “Unable…” which probably indicates that there is something else wrong on the Git host.

    This might help someone. When I was trying to clone a project from an EC2 instance, I was getting the below error:

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

    The resolution for me includes the below steps:

    1. Ensure SSH key (public) is added/updated in the EC2 instance.
    2. Ensure authentication agent (in my case its Pageant=Putty Authentication Agent) is running and the corresponding private key is loaded.
    3. Use the EC2 SSH key ID for the public key for git clone. Example:

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

    I had the same kind of problem after installing GIT on Windows. At first it worked; then, a day later (after a PC reboot), it didn’t anymore, and I got this:

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

    The problem was that after the reboot, the automatically started Putty “pageant.exe” didn’t have the private key active anymore. When you add a key in pageant, it’s not a persistent setting by default. I just had to add the key again, and it worked fine. So, for that case, it’s necessary to make pagenant load the key automatically, as discussed here:

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

    The error transformed in:
    fatal: protocol error: bad line length character: fata

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

    The problem seem to be an apostrophe added around the repository name: Looking with a tool like Process Monitor (from sys internals), that were added by the git client. It seems to be a git specific windows problem.

    I tried the same command line in the prompt of the server: the full error was “fatal: not a given repository (or any of the parent directories): .git”

    In conclusion, to me it seems like a software bug. Be advised that I am not a git expert, it is first time I use git, i come from subversion and perforce.

    I had the same problem as Christer Fernstrom. In my case it was a message I had put in my .bashrc that reminds me do do a backup when I haven’t done one in a couple of days.

    The following may help someone:
    When trying to clone a project I have on my AWS EC2 instance I was getting the following error:

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

    This was caused by trying to ssh as root instead of EC2-USER.
    if you actually ssh without doing a git clone… you will see the error msg in something along the lines of “Please login with ec2-user”
    Once I did a git clone as a ec2-user it was good.

    i also encounter that error once in a while, but when it does, it means that my branch is not up-to-date so i have to do git pull origin <current_branch>

    FYI I got this same error message after I upgraded a CentOS6 container to CentOS7 — some git operations started failing when building the container, e.g.

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

    Running ssh gave me an error I could search on:

    # ssh git@bitbucket.org
    Invalid clock_id for clock_gettime: 7
    

    That led me to https://github.com/wolfcw/libfaketime/issues/63 where I realized I had forgotten I had a LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 in a parent Dockerfile. Commenting that out fixed the error.

    For me it was becuase I recently added

    RequestTTY force
    

    into .ssh/config

    commenting this out allowed it to work

    Check if Shell access is allowed on the server.

    We ran into 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 gitty details about what went wrong, but in our case what triggered it was that the disk on the server was full.

    It could be a security access on your machine, are you running Pageant (which is a putty agent)?

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

    Well, I had this same issue (Windows 7). Try to get repo by password.
    I use Git Bash + Plink (environment variable GIT_SSH) + Pageant.
    Deleting GIT_SSH (temporary) helps me. I don’t know why I can’t use login by pass and login with RSA at the same time…

    In my case the problem was 32-bit Putty and pageant.exe – it can’t communicate with 64-bit TortoisePlink.exe. Replacing 32-bit Putty with a 64-bit version solved the problem.

    Git doesn’t prompt for password and fails with similar cryptic message “fatal: protocol error: bad line length character: user” if you don’t have your private key authentication setup as well.

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

    I had to struggle a bit on how to provide private key to the Git Bash on the windows machine. Dan McClain’s answer in https://serverfault.com/questions/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 describes that. One addition to his answer, in my case the private key file was expected to be named id_rsa.pub

    Late answer here, but hope it will help someone. If its a protocol error, it has to do something with your local git not able to communicate to the remote git. This can happen if you cloned the repo via ssh and sometime later, you lost the keys to the repo or your ssh agent cannot find those keys anymore.

    Solution

    1. Generate a new key and add it your git repo or configure your ssh agent to load the keys if you still have the keys with you & not with someone else 😉

    2. Another quick fix is to go to your .git directory and edit the config file’s [remote "origin"] url from git to http so that ssh keys are not needed to push and it will revert to asking 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/*
    
    Git Baby is a git and github fan, let's start git clone.