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

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

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.

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.

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.

You can get the actual error message by doing:

ssh [email protected] "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.

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.

sudo gitlab-ctl reconfigure 

and then

sudo gitlab-ctl restart 

should do the trick

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

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

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 

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.

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> 

change the shell of git

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

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.

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

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

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.

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.

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.

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

[remote "origin"] url = [email protected]:

As described here:

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

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.