148

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

Tito
  • 8,894
  • 12
  • 52
  • 86
user437899
  • 8,879
  • 13
  • 51
  • 71
  • Had similar issue with "fatal: protocol error: bad line length character: This", my error message was "This account is currently not available." – hj' Dec 21 '17 at 16:25
  • FWIW: I sometimes get a similar error at the very end of a git deploy to my Heroku app, but it seems to have no effect (the deploy succeeds). – Danra Aug 17 '22 at 03:42

34 Answers34

138

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.

Edward Thomson
  • 74,857
  • 14
  • 158
  • 187
  • 11
    That, and `ssh /bin/true` shouldn't output anything. – Stefan Näwe Nov 18 '11 at 07:34
  • 1
    Okay, the output from git-receive-pack is: "Unable to execute command or shell on remote system: Failed to Execute process." Iam able to connect with ssh via putty or other ssh-clients (git's ssh). but i cant doing git-stuff... – user437899 Nov 18 '11 at 07:58
  • i found the problem. ssh cant access the git methods. i have to reference to the git bash-functions. i think i have to edit the .bashc file in the ssh-server folder, but my attempts didnot work... – user437899 Nov 18 '11 at 11:01
  • 13
    I had this same issue and the cause was an 'echo ".bashrc"' in my .bashrc, so instead of "fatal: protocol error: bad line length character: Unab" I was seeing "fatal: protocol error: bad line length character: .bas". – snarkyname77 Jul 12 '13 at 19:02
  • 5
    Right, that was my problem too: my `.bashrc` at the machine that hosted the Git repository I was trying to pull from had a line that produced an echo to the standard output. (That is, I was the owner of the repository on the remote machine, so it was my `.bashrc` that caused the problem.) I used the trick given by user ruslo in another answer, namely redirecting the output of that command from stdout to stderr (`some_command 1>&2`). After that, `git pull` worked again. – Teemu Leisti Mar 17 '14 at 21:01
  • git-receive-pack: "This service allows sftp connections only.", please help. nvm, found answer here http://stackoverflow.com/questions/9163295/cloning-a-git-repository-over-sftp – happy_marmoset Mar 18 '16 at 10:26
  • 5
    With the above command, the output just hangs. It lists all my branches, one per line, and then on the final printed line I get the output `0000` and the cursor immediately after as if another line were to be written out but never completes. – demongolem May 17 '16 at 15:39
  • 1
    Any feedback you generate in say git hooks must go to stderr and not to stdout which is reserved to the git protocol. –  Jun 20 '16 at 00:37
  • 2
    While this answer is interesting, it provides little to none real solutions for the problem. – Dariusz Oct 12 '17 at 07:18
  • You're not wrong, @Dariusz. But without knowing what the error message _is_, I couldn't possibly tell you how to correct it. Run the `ssh` command I indicated, read the error message, and then you can go from there. – Edward Thomson Oct 12 '17 at 18:40
  • @demongolem how'd you solve that? I see 0000 as well. – judepereira Dec 08 '17 at 16:23
  • 8
    I hate to bump a seven year old issue, but I get the same 0000 issue with git-receive-pack. It hangs there until I press return four times, at which point it reports the same protocol error and quits. – Mark E. Hamilton Mar 08 '18 at 19:12
  • 1
    Those comments saved my day. Anything printed (echo-ed or similar) in your .bashrc can messed up the git command! – 4wk_ Apr 12 '18 at 07:58
  • 1
    For me the issue was simply that my SSH key was not added on the server (just a normal auth issue). The error message could have been a bit better :) – jakub.g Aug 20 '18 at 14:24
  • 1
    What exactly replaces ? I assume was just the URL to the git repository but that didn't seem to work. Could someone paste an example of this command filled in with a realistic looking input for host and path-to-git – Sidharth Ghoshal Feb 04 '19 at 22:09
  • 2
    @frogeyedpeas Just parse the URL or SCP path. If you're cloning `git@github.com:/user/repo.git` then host is `github.com` and the path is `user/repo.git`. So run `ssh github.com git-receive-pack /user/repo.git`. – Edward Thomson Feb 04 '19 at 22:46
  • 1
    similar error, ending in "This": https://stackoverflow.com/questions/22314298/git-push-results-in-fatal-protocol-error-bad-line-length-character-this – scrat.squirrel Apr 28 '19 at 00:37
  • I get with git clone: `fatal: protocol error: bad line length character: logi`. `ssh 192.168.178.36 git-receive-pack /gt_sr/doks.git` leads to (after 4 times return): `008d0000000000000000000000000000000000000000 capabilities^{} report-status delete-refs side-band-64k quiet atomic ofs-delta agent=git/2.11.0 0000 fatal: protocol error: bad line length character:`. The bad line length character changed to empty. I will now try to run the key agent of putty pageant. Before the protocol error git clone stopped at the cache question. I then started putty and it saved the key in the putty cache. – Timo Nov 02 '20 at 11:39
  • In my case, the 4 letters were the first 4 letters of my username. The problem was that I started to work with another machine, and I created a new .ssh credentials, but the server has stored the old credentials. The solution was to copy the C/Users/my.user/.shh files from the old machine to the new machine, and everything started to work! – Windgate Oct 18 '21 at 13:59
  • From what I understand it's the server trying to start the interactive login process,which confuses git. What I don't understand is that it used to work before but stopped working after upgrading git and its GUI clients. The fix seems to be to avoid passwords and use key based auth. – E. van Putten Jul 13 '23 at 08:53
73

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
janos
  • 120,954
  • 29
  • 226
  • 236
  • 7
    I had the same problem on Windows and turned out to be the same root cause for the opposite reason. I was trying to use Cygwin (and the embedded Git SSH) but GIT_SSH was set to C:\...\plink.exe which causing a conflict. Once I removed this everything worked fine. – Matt Holtzman Oct 04 '16 at 13:01
  • 11
    Removing GIT_SSH entry from the environment variables did the trick for me – chamalabey Jan 05 '17 at 22:45
  • Similar error after upgrading GitExt had to restart pageant and reimport .ppk key file. – Bill Dolan May 12 '17 at 17:53
  • 14
    I simply forgot to load the private key in pageant what ended in `fatal: protocol error: bad line length character: git@`. What a misleading error message. – Ludwig May 15 '18 at 20:02
  • 4
    In my case (Windows 10) pageant was not running. Once I started it up and added the private key to it, this Just Worked. – april26 Aug 28 '18 at 12:56
  • @Ludwig Many thanks - was exactly that for me as well. I'd updated the remote in GitExtensions but forgotten to associate my key file with the remote, and got that message. – Zhaph - Ben Duguid Jul 18 '19 at 12:20
  • If ssh works passwordless (key auth), do I still need pageant? Is pageant like a bridge for git and ssh? – Timo Nov 02 '20 at 15:53
  • Similar: ```fatal: protocol error: bad line length character: | Pa.``` Pageant needed a restart. A below entry indicated rebooting windows and restarting Pageant. I suspect that was overkill and restarting Pageant was all that was necessary (but I've been wrong before) – dneimeier Dec 26 '22 at 15:06
39

For GitExtension users:

I faced the same issue after upgrading git to 2.19.0

Solution:

Tools > Settings > Git Extensions > SSH

Select [OpenSSH] instead of [PuTTY]

enter image description here

Amit Shah
  • 7,771
  • 5
  • 39
  • 55
  • This is exactly what I've done, when you get the error `fatal: protocol error: bad line length character: git@`. Make sure that the SSH key is generated and added to *GitLab*. Perhaps the restart of *Git Extensions* was necessary. – testing May 06 '19 at 11:37
30

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

MaeseDude
  • 421
  • 4
  • 4
  • For me the situation was that in Visual studio I got error: "Git failed with a fatal error. protocol error: bad line length character: gitu" every time Windows got restarted. The pageant process was not started at all. I needed to use e.g. TortoiseGit that solved this on background and then GIT worked in Visual studio like a charm. – Honza P. Jan 07 '19 at 11:55
18

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
Christer Fernstrom
  • 612
  • 5
  • 12
  • In my (windows 10) case, the problem was the output of some docker related commands at my cmd startup init.cmd script (which I created by those instructions: stackoverflow.com/questions/17404165/…). but it's the same principal. thank you! – ET-CS Apr 02 '16 at 19:40
  • This was the case for me. I had a 'banner' command in my .bashrc. Commenting it out fixed the issue. Thank you :). – jamie Feb 27 '17 at 18:09
14

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

Stanley Emmanuel
  • 171
  • 1
  • 7
11

You can redirect any output from .bashrc to stderr:

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

git will ignore this symbols

  • That did it for me. I had a statement `rvm use 2.0.0-p353` in my `.bashrc`, which must have confused `git pull`. After appending `1>&2` and trying again, `git pull` worked fine. – Teemu Leisti Mar 17 '14 at 20:59
7

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.

syclee
  • 697
  • 7
  • 18
  • I see the same thing (Windows 10 64-bit) but running as administrator doesn't fix it. – Ed Avis Dec 15 '15 at 21:11
  • 5
    I have a hunch about what causes this. If you don't have the ssh keypair set up (or it is not readable for some reason) then ssh prompts for a password. On Windows there isn't a clear distinction between standard output and console output, so the password prompt goes to stdout: "git@whatever's password:". This is seen by git as corrupted protocol output. – Ed Avis Dec 15 '15 at 22:22
  • @EdAvis Thanks! I had the same problem and after reading your comment I double checked my key agent (which is usually run at startup on my machine). It turned out that it was not running for some reason ... – Gerrit-K Feb 03 '17 at 13:32
6

For me it was becuase I recently added 

RequestTTY force

into .ssh/config

commenting this out allowed it to work

Thu 01 Jan 1970 000000 GMT
  • 540
  • 6
  • 7
5

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

acveer
  • 370
  • 1
  • 4
  • 10
  • 4
    Note: This is because you're using plink, and if you do `plink ls` then the first thing plink prints to stdout is `login as`, which git appears to be trying to interpret as something important. A quick fix is to simply `unset GIT_SSH` and `unset SVN_SSH`. More info [here](https://www.bountysource.com/issues/30691481-username-required-when-cloning-with-plink) – Pod Feb 14 '17 at 08:41
  • @Pod you are right, on windows these commands should help: `set GIT_SSH=` and `set SVN_SSH=` – Maksim Kostromin Mar 13 '18 at 22:23
  • I had the same issue with TFS. After adding the key id everything works fine, thanks! – Andre Hofmeister Jan 17 '19 at 10:34
4

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

After reboot of Windows I had to start "PuTTY agent" (pageant.exe) again and add a private key that disappeared from a list of keys.

CoolMind
  • 26,736
  • 15
  • 188
  • 224
4

If you use Putty. Then make sure to have Pageant running and your private key is loaded in Pageant (mouse right-click on Pageant icon on the Taskbar and click "View keys" on the menu that pops up).

Otherwise when you do in cmd.exe :

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

you get this message "fatal: protocol error: bad line length character:"

Developer Marius Žilėnas
  • 5,813
  • 1
  • 41
  • 70
4

TL;DR: Do not omit username@ in your remote URLs when on Windows.

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

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

Because ssh's default behavior is to just use whatever username you're currently logged in with. If you're on Windows and have set up git to use plink.exe so that you can use the key loaded in your pageant, then this will not work, because plink does not have this same automatic username behavior, resulting in those cryptic error messages, because it will prompt for the username:

$ plink server-name
login as: _

Versus:

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

If you already cloned a repository somehow you can fix the remotes in your .git/config by adding the username@ to the remote URL.

jlh
  • 4,349
  • 40
  • 45
3

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.

snarkyname77
  • 1,154
  • 1
  • 10
  • 23
2

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>

bonbon.langes
  • 1,718
  • 2
  • 22
  • 37
2

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.

jamshid
  • 1,775
  • 17
  • 14
2

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.

Nikolai Koudelia
  • 2,494
  • 1
  • 26
  • 28
2

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

FMFF
  • 1,652
  • 4
  • 32
  • 62
Val
  • 21
  • 2
1

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.

Christopher Vickery
  • 53
  • 7
1

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.

ConfusedDeer
  • 3,335
  • 8
  • 44
  • 72
1

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

Shoonya
  • 118
  • 8
1

For me adding the same host details into Putty with the private key (convert with puttygen) worked. Any git bash commands after that had no problems.

David Aleu
  • 3,922
  • 3
  • 27
  • 48
1

Had some similar issue but git fatal: protocol error: bad line length character: Cann and I was not able getting rid of it until I got rid of all the plink.exe dependency (have installed the Putty via choco installer) but also removed the next line from the .gitconfig file sshCommand = plink -batch.

Silviu
  • 103
  • 1
  • 7
  • I had this error. I found that I could no longer run PuTTY. Uninstalled and re-installed PuTTY (via Chocolatey) and it fixed my Git error. – Phil Gilmore Apr 26 '22 at 17:06
0

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.

Razvan
  • 157
  • 1
  • 2
0

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.

anr78
  • 1,308
  • 2
  • 17
  • 31
0

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

Kevin Davis
  • 367
  • 1
  • 7
  • 25
0

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

Mohanakrrishna
  • 148
  • 3
  • 13
0

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...

Philipp Klemeshov
  • 383
  • 1
  • 5
  • 14
0

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/*
Tito
  • 8,894
  • 12
  • 52
  • 86
0

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

Hakaishin
  • 2,550
  • 3
  • 27
  • 45
0

I had same problem when I did git pull

git pull fatal: protocol error: bad line length character: <htm fatal: the remote end hung up unexpectedly

I changed my remote url HTTP to SSH, and it worked for me.

git remote set-url origin "HTTP" to "SSH"

Karthik N
  • 61
  • 2
  • 12
0

In my case, the issue is caused by a modified /bin/ssh. I work on a server with other people and the default /bin/ssh is somehow modified, it outputs unintended logs when starting. I restore the /bin/ssh to the correct executable and solved it.

Zhang Yu
  • 559
  • 6
  • 15
0

I know this is a rather old thread but when I had a very similar error message, I only got hints from this posts to investigate around SSH. I forgot that I put up an sshrc with an "echo" in it to test. So if you are running some form of UNIX, and get this error, then try looking into the following files:

  • /etc/sshrc: runs for any user login
  • ~/.ssh/rc: runs for a specific user login

If these scripts have stdout then I think it can confuse the SSH key exchange process. At least it did it for me. Removing the echoes lines fixed my issue.

Bence Musa
  • 17
  • 5
0

Check if Shell access is allowed on the server.

perpetual_dream
  • 1,046
  • 5
  • 18
  • 51
  • mine was "Hi g". turns out that i followed some Security Setup website and now my git login says "Hi git! You've successfully authenticated, but I do not provide interactive shell access.". guess ill have to remove that.... – don bright Feb 03 '20 at 01:02