Git Remoto: Erro: fatal: erro de protocolo: caractere de tamanho de linha incorreto: Unab

Eu configurei um servidor git e agora quero empurrar inicialmente meu repository do cliente. Eu usei git push origin master e receba esta mensagem de erro:

 fatal: protocol error: bad line length character: Unab 

Eu não sei o que está errado. Eu não sei o que é “Unab”. Eu tentei resize o shell, mas ainda é “Unab”. Não consigo encontrar uma solução para essa mensagem de erro.

Eu configuro o servidor com “authorized_keys” e SSH. (Eu posso me conectar a ele, usando o SSH.)

Parece ser um problema git?

BTW: O servidor está configurado em uma VM do Windows 7

Essa mensagem de erro é um pouco obtusa, mas o que ela está realmente tentando dizer é que o servidor remoto não respondeu com uma resposta adequada do git. Por fim, houve um problema no servidor executando o processo git-receive-pack .

No protocolo Git, os primeiros quatro bytes devem ser o comprimento da linha. Em vez disso, eles eram os personagens Unab … o que provavelmente é o começo de uma mensagem de erro de algum tipo. (isto é, provavelmente é ” Unable to... ” fazer alguma coisa).

O que acontece quando você executa o ssh git-receive-pack ? Você deve ver a mensagem de erro que o seu cliente git está baralhando e você pode corrigi-lo.

Eu tive problema semelhante, mas a mensagem de erro exata foi:

fatal: erro de protocolo: caractere de comprimento de linha incorreto: Usin

Isso é no Windows, com GIT_SSH definido para o caminho do plink.exe do PuTTY.

Possíveis problemas e soluções:

  • Certifique-se de que o caminho para o plink.exe esteja correto. O caminho do estilo Unix também funciona bem, por exemplo, /c/work/tools/PuTTY/plink.exe
  • Verifique se o agente principal do PuTTY ( pageant.exe ) está sendo executado
  • Certifique-se de que o agente chave contenha uma chave válida para acessar o servidor

Talvez você tenha uma instrução no .bashrc do servidor que produza saída. Eu, por exemplo, tive isto:

 [[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" rvm use ruby-1.9.3-p194@rails32 

Nesse caso, a saída do uso rvm será (erroneamente) interpretada como proveniente do git. Então substitua por:

 rvm use ruby-1.9.3-p194@rails32 > /dev/null 

Depois de carregar a chave privada do SSH nas Extensões do Git, esse problema é resolvido.

Eu tive o mesmo tipo de problema depois de instalar o GIT no Windows. No começo funcionou; então, um dia depois (depois de uma reboot do PC), isso não aconteceu mais, e eu percebi isso:

 $ git pull fatal: protocol error: bad line length character: git@ 

O problema foi que após a reboot, o Putty “pageant.exe” iniciado automaticamente não tinha mais a chave privada ativa. Quando você adiciona uma chave no concurso, não é uma configuração persistente por padrão. Eu só tive que adicionar a chave novamente, e funcionou bem. Então, para esse caso, é necessário fazer o pagenant carregar a chave automaticamente, como discutido aqui:

https://www.digitalocean.com/community/tutorials/how-to-use-pageant-to-streamline-ssh-key-authentication-with-putty

Você pode redirect qualquer saída de .bashrc para stderr :

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

git irá ignorar esses símbolos

Eu tive um problema semelhante no Windows usando o Git Bash. Eu continuei recebendo este erro ao tentar fazer um clone git. O repository estava em uma checkbox do Linux com o GitLab instalado.

 git clone git@servername:path/to/repo fatal: protocol error: bad line length character: git@ 

Eu me certifiquei de que a chave ssh foi gerada. A chave pública foi adicionada no GitLab. O ssh-agent estava em execução e a chave gerada foi adicionada ( link do github ).

Eu fiquei sem opções e finalmente tentei fechar o Git Bash e abri-lo novamente clicando com o botão direito do mouse em ‘Executar como Administrador’. Trabalhou depois disso.

Verifique seus arquivos de boot na conta usada para conectar-se à máquina remota para instruções “echo”. Para o shell Bash, estes seriam seus .bashrc e .bash_profile etc. Edward Thomson está correto em sua resposta, mas um problema específico que eu experimentei é quando há alguma impressão de placa de caldeira após o login em um servidor via ssh. O Git obterá os primeiros quatro bytes dessa placa e aumentará esse erro. Agora, neste caso específico, eu vou adivinhar que “Unab” é na verdade o trabalho “Unable …”, que provavelmente indica que há algo errado no host do Git.

Para mim foi porque eu adicionei recentemente

 RequestTTY force 

em .ssh / config

comentando isso permitiu que ele funcionasse

Isso pode ajudar alguém. Quando eu estava tentando clonar um projeto de uma instância do EC2, eu estava recebendo o erro abaixo:

 Cloning into 'repo1'... fatal: protocol error: bad line length character: logi 

A resolução para mim inclui os passos abaixo:

  1. Assegure-se de que a chave SSH (pública) seja adicionada / atualizada na instância do EC2.
  2. Assegure-se de que o agente de autenticação (no meu caso, o Pageant = Putty Authentication Agent) esteja em execução e que a chave privada correspondente seja carregada.
  3. Use o ID da chave SSH do EC2 para a chave pública do git clone. Exemplo:

    git clone ssh: // {Chave SSH ID}@someaccount.amazonaws.com/v1/repos/repo1

No meu caso, após a busca, ele foi escrito: fatal: protocol error: bad line length character: Pass . Além disso, após o envio, recebi: fatal: protocol error: bad line length character: git@ Done .

Após a reboot do Windows eu tive que iniciar “agente PuTTY” (pageant.exe) novamente e adicionar uma chave privada que desapareceu de uma lista de chaves.

O erro transformado em: fatal: erro de protocolo: caractere de comprimento de linha incorreto: fata

depois de adicionar o local do git-upload-pack ao caminho do sistema.

O problema parece ser um apóstrofo adicionado ao redor do nome do repository: Procurando com uma ferramenta como o Process Monitor (do sistema sys internals), que foram adicionados pelo cliente git. Parece ser um problema específico do windows git.

Eu tentei a mesma linha de comando no prompt do servidor: o erro completo foi “fatal: não um determinado repository (ou qualquer um dos diretórios pai): .git”

Em conclusão, para mim, parece um bug de software. Esteja ciente de que eu não sou um especialista em git, é a primeira vez que eu uso o git, eu venho da subversão e forçosamente.

Eu tive o mesmo problema que Christer Fernstrom. No meu caso, foi uma mensagem que eu coloquei no meu .bashrc que me lembra de fazer um backup quando eu não faço um em um par de dias.

O seguinte pode ajudar alguém: Ao tentar clonar um projeto que tenho em minha instância do AWS EC2, recebi o seguinte erro:

 Cloning into 'AWSbareRepo'... fatal: protocol error: bad line length character: Plea 

Isso foi causado pela tentativa de ssh como root em vez de EC2-USER. se você realmente ssh sem fazer um clone git … você verá a mensagem de erro em algo como “Por favor faça o login com ec2-user” Uma vez eu fiz um git clone como ec2-user foi bom.

Eu também encontro esse erro de vez em quando, mas quando isso acontece, significa que o meu branch não está atualizado, então eu tenho que fazer o git pull origin

FYI Eu recebi esta mesma mensagem de erro depois de atualizar um contêiner CentOS6 para o CentOS7 – algumas operações do git começaram a falhar ao construir o contêiner, por exemplo

 # git remote show origin fatal: protocol error: bad line length character: Inva 

Executar ssh me deu um erro que eu poderia pesquisar:

 # ssh git@bitbucket.org Invalid clock_id for clock_gettime: 7 

Isso me levou a https://github.com/wolfcw/libfaketime/issues/63 onde percebi que tinha esquecido que eu tinha um LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 em um Dockerfile pai. Comentando isso, corrigimos o erro.

Para mim, adicionando os mesmos detalhes do host em Putty com a chave privada (converter com puttygen) funcionou. Qualquer comando do git bash depois disso não teve problemas.

Eu tive o mesmo erro "fatal: protocol error: bad line length character: shmi" Onde o shmi é o nome de usuário no meu caso. Troquei o SSH do PuTTY para o OpenSSH em "Git Extensions->Settings->SSH" . Ajudou.

Nós nos deparamos com isso também.

 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 

Eu não sei os detalhes do gitty sobre o que deu errado, mas no nosso caso o que desencadeou foi que o disco no servidor estava cheio.

Pode ser um access de segurança na sua máquina, você está executando o Pageant (que é um agente putty)?

você sempre pode ter um link http para o seu projeto git. Você pode usar isso em vez do link ssh. Esta é apenas uma opção que você tem

Bem, eu tive esse mesmo problema (Windows 7). Tente obter o repo por senha. Eu uso o Git Bash + Plink (variável de ambiente GIT_SSH) + Pageant. Excluir GIT_SSH (temporário) me ajuda. Não sei porque não consigo usar o login by pass e faço login com o RSA ao mesmo tempo …

No meu caso, o problema era o Putty de 32 bits e o pageant.exe – ele não pode se comunicar com o TortoisePlink.exe de 64 bits. Substituir o Putty de 32 bits por uma versão de 64 bits resolveu o problema.

O Git não solicita a senha e falha com uma mensagem criptografada semelhante “fatal: erro de protocolo: caractere de comprimento de linha incorreto: usuário” se você não tiver sua configuração de autenticação de chave privada também.

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server informa como especificar a chave pública no servidor. Basicamente, adicione a chave pública em ~ / .ssh / authorized_keys ou ~ / .ssh / authorized_keys2

Eu tive que lutar um pouco sobre como fornecer chave privada para o Git Bash na máquina windows. A resposta de Dan McClain em https://serverfault.com/questions/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 descreve isso. Uma adição à sua resposta, no meu caso, esperava-se que o arquivo de chave privada fosse nomeado id_rsa.pub

Resposta tardia aqui, mas espero que ajude alguém. Se é um erro de protocolo, tem que fazer alguma coisa com o seu git local incapaz de se comunicar com o git remoto. Isso pode acontecer se você clonar o repository via ssh e, algum tempo depois, perder as chaves do repository ou o agente ssh não conseguir mais encontrá-las.

Solução

  1. Gere uma nova chave e adicione seu git repo ou configure seu agente ssh para carregar as chaves se você ainda tiver as chaves com você e não com outra pessoa;)

  2. Outra solução rápida é ir para o seu diretório .git e editar o [remote "origin"] url do [remote "origin"] url config [remote "origin"] url do git para http modo que as chaves ssh não sejam necessárias para push e ele será revertido para pedir seu nome de usuário e senha.

     [remote "origin"] url = git@gitlab.*****.com:****/****.git fetch = +refs/heads/*:refs/remotes/origin/* 

Mudar para

  [remote "origin"] url = http://gitlab.*****.com/****/****.git fetch = +refs/heads/*:refs/remotes/origin/* 

Mudando o sect exectuable de builtin para nativ sob settings / version control / git fez o truque para mim.

Verifique se o access Shell é permitido no servidor.