Reputation: 9259
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
Upvotes: 159
Views: 268251
Reputation: 318
In my case, from GIT windows to a remote GIT on pi raspberry server, using this command:
GIT_SSH_COMMAND="ssh -p 22" git push origin master
instead of
git push origin master
solved the problem
Upvotes: 0
Reputation: 9044
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
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 ;)
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/*
Upvotes: 0
Reputation: 624
I too had this issue...
fatal: protocol error: bad line length character: fata
What resolved my issue was updating GIT...
$ brew upgrade git
Upvotes: 1
Reputation: 445
If any one has changed the buffer size, then this is for you, this line of command will reset it :
git config --global http.postBuffer 1048576
Upvotes: 3
Reputation: 17
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 loginIf 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.
Upvotes: 0
Reputation: 123
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
.
Upvotes: 1
Reputation: 669
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.
Upvotes: 0
Reputation: 69
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"
Upvotes: 0
Reputation: 4677
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.
Upvotes: 5
Reputation: 6119
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:"
Upvotes: 4
Reputation: 8179
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]
Upvotes: 42
Reputation: 28793
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.
Upvotes: 5
Reputation: 2932
Changing the ssh exectuable from builtin to nativ under settings/version control/git did the trick for me.
Upvotes: 0
Reputation: 21
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.
Upvotes: 2
Reputation: 3942
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.
Upvotes: 1
Reputation: 128
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
Upvotes: 1
Reputation: 2639
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.
Upvotes: 2
Reputation: 78673
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.
Upvotes: 142
Reputation: 451
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:
Upvotes: 33
Reputation: 380
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:
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
Upvotes: 5
Reputation: 557
For me it was becuase I recently added
RequestTTY force
into .ssh/config
commenting this out allowed it to work
Upvotes: 6
Reputation: 413
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...
Upvotes: 0
Reputation: 168
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
Upvotes: 0
Reputation: 365
It could be a security access on your machine, are you running Pageant (which is a putty agent)?
Upvotes: 0
Reputation: 124646
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:
plink.exe
is correct. Unix style path works fine too, for example /c/work/tools/PuTTY/plink.exe
pageant.exe
) is runningUpvotes: 78
Reputation: 181
After loading the SSH private key in Git Extensions, this issue gets resolved.
Upvotes: 15
Reputation: 697
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.
Upvotes: 7
Reputation: 1775
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 [email protected]
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.
Upvotes: 2
Reputation: 1818
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>
Upvotes: 2
Reputation: 3415
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.
Upvotes: 1