Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

git 2.14.0 protocol error: bad line length character: Not #1258

Closed
1 task done
k-mack opened this issue Aug 6, 2017 · 14 comments
Closed
1 task done

git 2.14.0 protocol error: bad line length character: Not #1258

k-mack opened this issue Aug 6, 2017 · 14 comments
Labels
bug git
Milestone
v2.14.0(2)

Comments

@k-mack
Copy link

k-mack commented Aug 6, 2017 •
edited
Loading

  • I was not able to find an open or closed issue matching what I'm seeing

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options

git version 2.14.0.windows.1
built from commit: 8d74ef6015f82b428680388d508def2af1e03932
sizeof-long: 4
machine: x86_64
  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]
  • What options did you set as part of the installation? Or did you choose the
    defaults?
# One of the following:
$ cat /etc/install-options.txt

Path Option: BashOnly
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

No.

Details

  • Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

git fetch
git clone
  • What did you expect to occur after running these commands?

Download commits from remote "origin."

  • What actually happened instead?

The following error was returned:

fatal: protocol error: bad line length character: Not
  • If the problem was occurring with a specific repository, can you provide the
    URL to that repository to help us with testing?

The problem only occurs with repositories being internally hosted on a server running GitLab 6.0.1. When I downgrade to Git for Windows 2.13.3, fetch and clone works as expected.
@shiftkey
Copy link

shiftkey commented Aug 6, 2017

The problem only occurs with repositories being internally hosted on a server running GitLab 6.0.1.

Can you reproduce this with a public GitLab repository? Is it an SSH or HTTPS remote?

Also, please set GIT_TRACE=1 and GIT_CURL_VERBOSE=1 when running a Git network command and attach the output here, so we can troubleshoot this more easily...

@k-mack k-mack changed the title git 2.14.0 git 2.14.0 protocol error: bad line length character: Not Aug 6, 2017
@k-mack
Copy link
Author

k-mack commented Aug 6, 2017

It is an SSH remote.

$ GIT_TRACE=1 GIT_CURL_VERBOSE=1 git remote -v
16:23:13.517865 git.c:328               trace: built-in: git 'remote' '-v'
origin  [email protected]:user/repository.git (fetch)
origin  [email protected]:user/repository.git (push)

$ GIT_TRACE=1 GIT_CURL_VERBOSE=1 git fetch origin
16:21:52.787228 git.c:328               trace: built-in: git 'fetch' 'origin'
16:21:52.803828 run-command.c:626       trace: run_command: 'ssh' '[email protected]' 'git upload-pack '\''user/repository.git'\'''
fatal: protocol error: bad line length character: Not

@shiftkey shiftkey mentioned this issue Aug 6, 2017
Closed
@k-mack
Copy link
Author

k-mack commented Aug 6, 2017

When running with Git for Windows 2.13.3, I get the following output:

$ GIT_TRACE=1 GIT_CURL_VERBOSE=1 git remote -v
16:30:44.438639 git.c:322               trace: built-in: git 'remote' '-v'
origin  [email protected]:user/repository.git (fetch)
origin  [email protected]:user/repository.git (push)

$ GIT_TRACE=1 GIT_CURL_VERBOSE=1 git fetch origin
16:30:49.330052 git.c:322               trace: built-in: git 'fetch' 'origin'
16:30:49.345652 run-command.c:626       trace: run_command: 'ssh' '[email protected]' 'git-upload-pack '\''user/repository.git'\'''
16:30:51.280857 run-command.c:626       trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
16:30:51.422258 run-command.c:626       trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
16:30:51.455458 git.c:322               trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
16:30:51.597858 run-command.c:1452      run_processes_parallel: preparing to run up to 1 tasks
16:30:51.597858 run-command.c:1484      run_processes_parallel: done
16:30:51.597858 run-command.c:626       trace: run_command: 'gc' '--auto'
16:30:51.660258 git.c:322               trace: built-in: git 'gc' '--auto'

@shiftkey
Copy link

shiftkey commented Aug 6, 2017

@k-mack let's focus on the failing ssh command as it looks like it's not able to connect.

You can test out your SSH connection with tracing enabled using this command:

 ssh -vvv -o LogLevel=DEBUG3 -T [email protected]

It's very verbose, but should yield some interesting clues around why it's failing for you.

@kostix
Copy link

kostix commented Aug 7, 2017

IMO that

fatal: protocol error: bad line length character: Not

it pretty telling.

I'd specilate that the remote SSH server responds directly with something like "Not authorized blah blah" instead of running the intended Git command which the local Git instance expects to communicate with instead.

So yes, I'm with @shiftkey on this: you should try to reproduce the problem by running the SSH client in a way Git itself runs it and see why it fails.

@nalla
Copy link

nalla commented Aug 7, 2017

Hi, I also have problems with ssh. But for me the culprit is Bitbucket (Internally hosted).

I have the following output with git fetch

λ git fetch
10:05:56.270840 git.c:328               trace: built-in: git 'fetch'
10:05:56.280808 run-command.c:626       trace: run_command: 'ssh' '[email protected]' 'git upload-pack '\''/foo/bar.git'\'''
Bitbucket cannot not execute "git upload-pack '/foo/bar.git'". The command is not supported as entered.

Ensure you are using a supported SCM, check the syntax and try again.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

When I use $env:GIT_SSH_COMMAND="ssh -vvv", I'll get the following output:

0:07:36.211643 git.c:328               trace: built-in: git 'fetch'
10:07:36.218643 run-command.c:626       trace: run_command: 'ssh -vvv' '[email protected]' 'git upload-pack '\''/foo/bar.git'\'''
OpenSSH_7.5p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data /c/Users/FBar/.ssh/config
debug1: /c/Users/FBar/.ssh/config line 6: Applying options for bitbucket.internal.net
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "bitbucket.internal.net" port 7999
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to bitbucket.internal.net [10.200.4.55] port 7999.
debug1: Connection established.
debug1: identity file /c/Users/FBar/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/FBar/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/FBar/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/FBar/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/FBar/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/FBar/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/FBar/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/FBar/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version SSHD-UNKNOWN
debug1: no match: SSHD-UNKNOWN
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to bitbucket.internal.net:7999 as 'git'
debug3: put_host_port: [bitbucket.internal.net]:7999
debug3: hostkeys_foreach: reading file "/c/Users/FBar/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /c/Users/FBar/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys from [bitbucket.internal.net]:7999
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa,[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: aes128-ctr,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc
debug2: ciphers stoc: aes128-ctr,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc
debug2: MACs ctos: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug3: send packet: type 30
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-rsa SHA256:OnT1mpRwm3so6QX/VNYsokAhARXXwRKWEdgVwjxuSR4
debug3: put_host_port: [10.200.4.55]:7999
debug3: put_host_port: [bitbucket.internal.net]:7999
debug3: hostkeys_foreach: reading file "/c/Users/FBar/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /c/Users/FBar/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys from [bitbucket.internal.net]:7999
debug3: hostkeys_foreach: reading file "/c/Users/FBar/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /c/Users/FBar/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys from [10.200.4.55]:7999
debug1: Host '[bitbucket.internal.net]:7999' is known and matches the RSA host key.
debug1: Found key in /c/Users/FBar/.ssh/known_hosts:4
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug2: key: /c/Users/FBar/.ssh/id_rsa (0x60006bd40)
debug2: key: /c/Users/FBar/.ssh/id_dsa (0x0)
debug2: key: /c/Users/FBar/.ssh/id_ecdsa (0x0)
debug2: key: /c/Users/FBar/.ssh/id_ed25519 (0x0)
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /c/Users/FBar/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp SHA256:eGc58BocfXsh6q14hPAPWOUKIIZh85+2Fz8Cz+xJixw
debug3: sign_and_send_pubkey: RSA SHA256:eGc58BocfXsh6q14hPAPWOUKIIZh85+2Fz8Cz+xJixw
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to bitbucket.internal.net ([10.200.4.55]:7999).
debug2: fd 4 setting O_NONBLOCK
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x08
debug2: client_session2_setup: id 0
debug1: Sending command: git upload-pack '/foo/bar.git'
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 2097152 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd ext data 181
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: obuf_empty delayed efd 6/(181)
Bitbucket cannot not execute "git upload-pack '/foo/bar.git'". The command is not supported as entered.

Ensure you are using a supported SCM, check the syntax and try again.
debug2: channel 0: written 181 to efd 6
debug3: channel 0: will not send data after close
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

debug3: send packet: type 1
debug3: fd 0 is not O_NONBLOCK
debug3: fd 1 is not O_NONBLOCK
Transferred: sent 2760, received 2056 bytes, in 0.0 seconds
Bytes per second: sent 95449.3, received 71102.8
debug1: Exit status 1
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

@kostix
Copy link

kostix commented Aug 7, 2017

I'm pretty sure Baldurien in this post has actually nailed the issue:

I am under the assumption this fix here is the responsible : https://github.com/git-for-windows/git/blob/40023e58cda656326287d77358514acb262b7484/connect.c as it replaces "git-xxx" by "git xxx" which could be badly interpreted by Gitolite.

This was working with previous version Git-2.13.3-64-bit.exe.

@dscho dscho closed this as completed in 0f33428 Aug 7, 2017
@dscho
Copy link
Member

dscho commented Aug 7, 2017

Thanks, everybody, especially Baldurien! This is a pretty bad regression...

@nalla
Copy link

nalla commented Aug 7, 2017

Maybe this is just a quoting issue on the remote side? Just to throw in a direction to get a fix on the way that will get you best of both worlds?

@dscho
Copy link
Member

dscho commented Aug 7, 2017

From your output, it looks as if BitBucket looks at argv[0] (typically git-upload-pack, with the regression git) to determine whether it is a permitted command.

So I think it is by design that git is rejected while git-upload-pack is not.

@kostix
Copy link

kostix commented Aug 7, 2017

@nalla I'm afraid this might has something to do with the fact the remotes might use special restricted shells to run Git commands which might have their own ideas about what is permitted to run and what is not.

So they should all get fixed first which seems like a long road ahead ;-)

@dscho
Copy link
Member

dscho commented Aug 7, 2017

Could y'all please test the latest snapshot at https://wingit.blob.core.windows.net/files/index.html ? Thanks!

@dscho dscho added this to the v2.14.0(1) milestone Aug 7, 2017
@nalla
Copy link

nalla commented Aug 7, 2017

@dscho works!

@dscho
Copy link
Member

dscho commented Aug 7, 2017

Thanks for the feedback! FWIW I think that #1257 has the same underlying root cause.

dscho added a commit to git-for-windows/build-extra that referenced this issue Aug 7, 2017
@dscho
Mention Bug Fix in release notes
69b54c9 
A regression introduced in v2.14.0 that prevented fetching via SSH
[was fixed](git-for-windows/git#1258).

Signed-off-by: Johannes Schindelin <[email protected]>
@redmanmale redmanmale mentioned this issue Aug 7, 2017
Closed
1 task
dscho added a commit that referenced this issue Aug 8, 2017
@dscho
Revert "git_connect: prefer Git's builtins over dashed form"
fa599f0 
It would appear that this change (which was intended to fix tests
interacting with local repositories when `git-upload-pack` was not in the
`PATH`) regresses on SSH access.

This reverts commit 40023e5 and fixes
#1258.

Signed-off-by: Johannes Schindelin <[email protected]>
dscho added a commit that referenced this issue Aug 8, 2017
@dscho
Revert "git_connect: prefer Git's builtins over dashed form"
a44076f 
It would appear that this change (which was intended to fix tests
interacting with local repositories when `git-upload-pack` was not in the
`PATH`) regresses on SSH access.

This reverts commit 40023e5 and fixes
#1258.

Signed-off-by: Johannes Schindelin <[email protected]>
git-for-windows-ci pushed a commit that referenced this issue Aug 8, 2017
@dscho
Revert "git_connect: prefer Git's builtins over dashed form"
64342c9 
It would appear that this change (which was intended to fix tests
interacting with local repositories when `git-upload-pack` was not in the
`PATH`) regresses on SSH access.

This reverts commit 40023e5 and fixes
#1258.

Signed-off-by: Johannes Schindelin <[email protected]>
git-for-windows-ci pushed a commit that referenced this issue Aug 10, 2017
@dscho
Revert "git_connect: prefer Git's builtins over dashed form"
2235522 
It would appear that this change (which was intended to fix tests
interacting with local repositories when `git-upload-pack` was not in the
`PATH`) regresses on SSH access.

This reverts commit 40023e5 and fixes
#1258.

Signed-off-by: Johannes Schindelin <[email protected]>
git-for-windows-ci pushed a commit that referenced this issue Aug 10, 2017
@dscho
Revert "git_connect: prefer Git's builtins over dashed form"
a7b8007 
It would appear that this change (which was intended to fix tests
interacting with local repositories when `git-upload-pack` was not in the
`PATH`) regresses on SSH access.

This reverts commit 40023e5 and fixes
#1258.

Signed-off-by: Johannes Schindelin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug git
Projects
None yet
Milestone
v2.14.0(2)
Development

No branches or pull requests
5 participants
@kostix @dscho @shiftkey @nalla @k-mack