Git push results in fatal: protocol error: bad line length character: This

Question

I am trying to get GitLab working on my server (running CentOS 6.5). I followed the gitlab-receipe to the line, but I just can't get it working. I am able to access the web interface, create new projects but pushing to the master branch returns the following error :

fatal: protocol error: bad line length character: This

I have done checks on the production environment, here are the results :

Checking Environment ...

Git configured for git user? ... yes

Checking Environment ... Finished

Checking GitLab Shell ...

GitLab Shell version >= 1.7.9 ? ... OK (1.8.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
update hook up-to-date? ... yes
update hooks in repos are links: ... 
ASC / Wiki ... repository is empty
Running /home/git/gitlab-shell/bin/check
Check GitLab API access: OK
Check directories and files: 
    /home/git/repositories: OK
    /home/git/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.4.10
Send ping to redis server: PONG
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking LDAP ...

LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab ...

Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... no
  Try fixing it:
  Redownload the init script
  For more information see:
  doc/install/installation.md in section "Install Init Script"
  Please fix the error above and rerun the checks.
projects have namespace: ... 
ASC / Wiki ... yes
Projects have satellites? ... 
ASC / Wiki ... can't create, repository is empty
Redis version >= 2.0.0? ... yes
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (1.8.3)

Checking GitLab ... Finished

For the init script error, the receipt says

Do not mind about that error if you are sure that you have downloaded the up-to-date

so as I have downloaded the latest one, I can't really do much about it.

I've been banging my head for the past week, and can not figure out why this error is occurring, any help would appreciated!!

Answer 1

If anyone else has this problem, the solution is to change the login shell of the user 'git' (or whatever your user is called) to /bin/bash. This can be done via the command : usermod -s /bin/bash git (Link). The reason for changing the login shell is because the default shell for the git user is /sbin/nologin (or similar, depending on environment), which prevents the git application from logging in as the git user on the git server.

Answer 2

Just for other users reference:

fatal: protocol error: bad line length character: no s
can be a truncated answer for "No such project".

As in my case, this kind of error can be fixed by adding user (even yourself) to the project in gitlab:

https://gitlab.com/username/your_project/project_members

also, ensure your public key is set in your user Profile settings > SSH Key or in Project > Settings > Deploy Keys

https://gitlab.com/profile/keys

Answer 3

Another thing to check is that your .bashrc does not print extra stuff. For example 'echo "hello"' in .bashrc creates the error:

kruus@borg:~/malt$ ssh snake01
Last login: Tue Oct 21 10:44:31 2014 from 138.15.166.103
hello
...
kruus@snake01:/net/snake01/usr/hydra/kruus/malt$ git pull
fatal: protocol error: bad line length character: hell

Note how saying hello caused one hell of a problem.

Removing the 'echo "hello"' from my .bashrc allows git to work as expected again. You may need to ">& /dev/null" to remove output if your .bashrc does more complicated things.

Answer 4

The solution to my issue with this was that I'd forgotten to add in a deploy key for the project (for the user I was trying to deploy as).

Adding a deploy key in https://gitlab/group/project/deploy_keys sorted me out.

Answer 5

Another possibility is that you misspelled the repository name.

I've done it twice in the last two days. I added a remote and misspelled it and I misspelled the name when creating the project on GitLab.

In both cases when I tried to push to remote I got

fatal: protocol error: bad line length character: No s

So check that spelling!

Also, if you create the project under a different name (like a group) make sure that's the remote you add.

Answer 6

You can get the actual error message by doing:

ssh git@yourgitlabserver.com "git-upload-pack yournamespace/yourreponame.git"

According to this git documentation git protocol expects at the beginning of each line its size and then the content. Looks like GitLab doesn't do that and sends the error message directly.

Answer 7

I experienced this error message today ("No s"), and it actually had to do with me having no rights to push to the targeted repository. Even though the error message is very weird, this might help people continue to work.

We use Gitlab.

Answer 8

sudo gitlab-ctl reconfigure

and then

sudo gitlab-ctl restart

should do the trick

Answer 9

In my case (private key over ~/.ssh/config) I had to leave out the ssh part in:

git clone ssh://git@hostname:username/repository.git

It worked with:

git clone git@hostname:username/repository.git

Error message was:

fatal: protocol error: bad line length character: No s

Answer 10

In my case, my username was changed and this repository's git config was not updated to match the new name.

Check your git remotes to make sure they are pointing to correct place:

git remote -v

Update the config by editing the config manually:

vim .git/config

or through commands

git remote set-url origin https://github.com/USERNAME/OTHERREPOSITORY.git

Answer 11

When I wanted to push my commits, I got this error:

fatal: protocol error: bad line length character: No s

I solved this just by a ssh connection check:

ssh Git@hostIp

Answer 12

Adding my experience to this already long list of possible solutions.

In my case I had the access to the repo I cloned, but no access to some other internal repos the package.json was referring to as dependencies or devDependencies. So the solution was getting access to these repos as well.

Answer 13

I had this same issue and turned out that I was working on a git branch. All I needed to do was push to the master.

$ git push <remote> <local branch name>:<remote branch to push into>

Answer 14

change the shell of git

usermod -s /usr/bin/git-shell git

Answer 15

Just adding a possible solution to others in my situation. In my case I was trying to push a tag.

git push heroku MYTAG:master

It wasn't until I dereferenced the tag that it worked

git push heroku MYTAG^{}:master

You can read more about it here: What does ^{} mean in git?

<rev>^{}, e.g. v0.99.8^{}

A suffix ^ followed by an empty brace pair means the object could be a tag, and dereference the tag recursively until a non-tag object is found.

Answer 16

The solution for me was to unset the GIT_SSH env variable which was pointing to putty (plink.exe)

Answer 17

Had the same issue, in my case the origin repo had been moved, changing .git/config solved my problem.

Answer 18

My error was: fatal: protocol error: bad line length character: No s

This was caused because I forgot to specify the SCM-tag in the pom.xml of my Maven-project, so it used the SCM-information from the parent project instead. I also had to add our Jenkins user to the project in GitLab.

Answer 19

In my case that error was fixed by changing remote git-user shell to git-shell using chsh:

chsh -s $(command -v git-shell) git

Official git-shell documentation. For security reasons it is highly recommended to use this shell for git-user on remote repository server.

Answer 20

In my case I was observing this error only in "SSH Extensions" for Windows.

The same command worked from command line. I switched SSH setting from PuTTY to OpenSSH and it stopped generating error.

Answer 21

My solution on Windows was switching the connection to SSH in .git/config:

[remote "origin"] url = git@github.com:

As described here:

https://help.github.com/en/articles/changing-a-remotes-url

Answer 22

Another one...

My configuration is a bit convoluted. On the server side, I use a self-hosted Git platform known as Gogs (mostly because it's written in Go, and I ❤️ Go!). Gogs has a built-in SSH server for the updates, but it still requires some 'help' from the main SSH server (which acts as a sort of proxy or front-end), usually running under the same user as Gogs (normally git, but that's up to the system administrator).

Now, recently, I have been trying to restrict access via shell accounts, giving them SFTP access in most cases; and I've moved the few remaining FTP accounts (yikes!) to SFTP as well. While doing that, I finally managed to track down an error on the SSHD configuration, which has prevented my setup to be more automated (basically, add a user to either the SFTP group or SSH group to give them access; I had to reload SSHD every time I added another user, which was a pain... especially if some mistake creeped in and I'd lose SSH access to my remote server!!). After all those changes, I did test quite a lot of accounts, saw that they were working, but didn't notice a tiny teeny mistake: the user git was in both groups (SFTP and SSH). Due to the way SSHD is configured, it would look up the SFTP group first, and SSH next. Because this user was on both, SSHD would then give it SFTP access only (this is independent from whatever shell is assigned to the user). So, what happened was that the following error message was echo'ed out:

PTY allocation request failed on channel 0
This service allows sftp connections only.
Connection to my.server.name closed.

Note that the first line (as well as the last) are very likely 'local' messages from the console's session manager. The error that git was receiving was, of course, This service allows sftp connections only., and thus it got the first four letters — This — prompting the error.

Making sure that the git user was only in the shell-access group fixed the issue:

PTY allocation request failed on channel 0
Hi there, You've successfully authenticated, but Gogs does not provide shell access.
If this is unexpected, please log in with password and setup Gogs under another user.

This is the expected behaviour when using Gogs: although from the perspective of the system it's 'allowing' shell accounts (and that's the only way to get it to work), these connections are being captured by Gogs, which knows that it should not allow any shell accounts whatsoever — the SSH protocol is just used to allow a Git push/pull and uses its own authentication (managed inside Gogs — not at the OS level).

I know, this is very likely an edge case affecting 0.000000000000001% of all people who were redirected to this answer via Google 😄

My point here is simple: the infamous fatal: protocol error: bad line length character: This can come from the line This service allows sftp connections only. meaning that the user you've got doesn't have access to a full shell account. This ought to give you at least a hint on what to start searching for — a configuration error for the Git user, either at the SSHD level or at the user ID/groups level.