Git Remote: Erro: fatal: erro de protocolo: caractere de comprimento de linha inválido: Unab


119

Eu configurei um servidor git e quero agora enviar inicialmente meu repo do cliente. Usei git push origin mastere recebo esta mensagem de erro:

fatal: protocol error: bad line length character: Unab

Eu não sei o que está errado. Não sei o que é "Unab". Tentei redimensionar o shell, mas ainda está "Unab". Não consigo encontrar uma solução para esta mensagem de erro.

Eu configurei o servidor com "authorized_keys" e SSH. (Posso me conectar a ele, usando SSH.)

Parece ser um problema git?

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


Tive um problema semelhante com "fatal: erro de protocolo: caractere de comprimento de linha inválido: Este", minha mensagem de erro era "Esta conta não está disponível no momento."
hj '21 de

Respostas:


117

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

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. (ou seja, é provavelmente " Unable to..." fazer algo).

O que acontece quando você corre ssh <host> git-receive-pack <path-to-git-repository>? Você deve ver a mensagem de erro de que seu cliente git está vomitando e pode ser capaz de corrigi-lo.


10
Isso e ssh <host> /bin/truenão deve produzir nada.
Stefan Näwe

9
Eu tive o mesmo problema e a causa foi um 'echo ".bashrc"' em meu .bashrc, então, em vez de "fatal: erro de protocolo: caractere de comprimento de linha inválido: Unab" Eu estava vendo "fatal: erro de protocolo: comprimento de linha inválido personagem: .bas ".
snarkyname77

4
Certo, esse era o meu problema também: .bashrcna máquina que hospedava o repositório Git de onde eu estava tentando extrair, havia uma linha que produzia um eco na saída padrão. (Ou seja, eu era o dono do repositório na máquina remota, então foi o meu .bashrcque causou o problema.) Usei o truque dado pelo usuário ruslo em outra resposta, ou seja, redirecionar a saída desse comando de stdout para stderr ( some_command 1>&2) Depois disso, git pullfuncionou novamente.
Teemu Leisti

2
Com o comando acima, a saída apenas trava. Ele lista todos os meus ramos, um por linha e, em seguida, na linha final impressa, recebo a saída 0000 e o cursor imediatamente depois, como se outra linha fosse escrita, mas nunca completa.
demongolem

2
Odeio esbarrar em um problema de sete anos, mas obtenho o mesmo problema 0000 com git-receive-pack. Ele fica parado lá até que eu pressiono a tecla Enter quatro vezes, quando então informa o mesmo erro de protocolo e fecha.
Mark E. Hamilton,

60

Tive um problema semelhante, mas a mensagem de erro exata foi:

fatal: erro de protocolo: caractere de comprimento de linha inválido: Usin

Isso está no Windows, com GIT_SSHo caminho definido para plink.exedo PuTTY.

Possíveis problemas e soluções:

  • Certifique-se de que o caminho para plink.exeestá correto. O caminho de estilo Unix também funciona bem, por exemplo/c/work/tools/PuTTY/plink.exe
  • Certifique-se de que o agente principal do PuTTY ( pageant.exe) esteja em execução
  • Certifique-se de que o agente de chave contém uma chave válida para acessar o servidor

7
Eu tive o mesmo problema no Windows e acabou sendo a mesma causa raiz pelo motivo oposto. Eu estava tentando usar o Cygwin (e o Git SSH incorporado), mas GIT_SSH foi definido como C: \ ... \ plink.exe, o que causou um conflito. Depois de remover isso, tudo funcionou bem.
Matt Holtzman

11
Remover a entrada GIT_SSH das variáveis ​​de ambiente funcionou para mim
chamalabey

Erro semelhante após a atualização do GitExt teve que reiniciar o pageant e reimportar o arquivo de chave .ppk.
Bill Dolan

9
Simplesmente esqueci de carregar a chave privada no concurso que terminava em fatal: protocol error: bad line length character: git@. Que mensagem de erro enganosa.
Ludwig

1
No meu caso (Windows 10), o concurso não estava funcionando. Assim que iniciei e adicionei a chave privada a ele, isso funcionou.
abril

28

Para usuários GitExtension:

Eu enfrentei o mesmo problema depois de atualizar o git para 2.19.0

Solução:

Ferramentas> Configurações> Extensões Git> SSH

Selecione [ OpenSSH ] em vez de [ PuTTY ]

insira a descrição da imagem aqui


Isso é exatamente o que eu fiz, quando você obtiver o erro fatal: protocol error: bad line length character: git@. Certifique-se de que a chave SSH seja gerada e adicionada ao GitLab . Talvez o reinício das extensões Git fosse necessário.
teste de

20

Tive o mesmo tipo de problema após instalar o GIT no Windows. No início funcionou; então, um dia depois (após uma reinicialização do PC), não parou mais, e eu peguei o seguinte:

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

O problema era que, após a reinicialização, o Putty "pageant.exe" iniciado automaticamente não tinha mais a chave privada ativa. Quando você adiciona uma chave no pageant, não é uma configuração persistente por padrão. Eu só tive que adicionar a chave novamente e funcionou bem. Portanto, para esse caso, é necessário fazer com que o pagenant carregue a chave automaticamente, conforme discutido aqui:

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


Para mim, a situação era que no Visual Studio eu recebia o erro: "Git falhou com um erro fatal. Erro de protocolo: caractere de comprimento de linha inválido: gitu" sempre que o Windows era reiniciado. O processo do concurso não foi iniciado. Eu precisei usar, por exemplo, o TortoiseGit que resolveu isso no fundo e então o GIT funcionou no Visual Studio como um encanto.
Honza P.

18

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

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

Neste caso, a saída do uso do rvm será (erroneamente) interpretada como vinda do git. Portanto, substitua-o por:

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

No meu caso (Windows 10), o problema era a saída de alguns comandos relacionados ao docker em meu script init.cmd de inicialização do cmd (que criei por essas instruções: stackoverflow.com/questions/17404165/…). mas é o mesmo princípio. obrigado!
ET-CS,

Este foi o meu caso. Eu tinha um comando 'banner' no meu .bashrc. Comentar corrigiu o problema. Obrigado :).
Jamie

12

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


1
para mim - adicionando a chave privada ssh ao concurso
Nick Grealy

10

Você pode redirecionar qualquer saída de .bashrcpara stderr:

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

git irá ignorar estes símbolos


Isso fez tudo para mim. Tive uma declaração rvm use 2.0.0-p353em meu .bashrc, que deve ter confundidogit pull . Depois de anexar 1>&2e tentar novamente, git pullfuncionou bem.
Teemu Leisti

7

Tive um problema semelhante no Windows usando Git Bash. Continuei recebendo este erro ao tentar fazer um clone do git. O repositório estava em uma caixa Linux com GitLab instalado.

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

Verifiquei se a chave ssh foi gerada. A chave pública foi adicionada ao GitLab. O ssh-agent estava em execução e a chave gerada foi adicionada ( link do github ).

Fiquei sem opções e finalmente tentei fechar o Git Bash e abri-lo novamente clicando com o botão direito em 'Executar como Administrador'. Trabalhou depois disso.


Vejo a mesma coisa (Windows 10 de 64 bits), mas executar como administrador não corrige.
Ed Avis

4
Tenho um palpite sobre o que causa isso. Se você não tiver o par de chaves ssh configurado (ou se ele não for legível por algum motivo), o ssh solicitará uma senha. No Windows não há uma distinção clara entre a saída padrão e a saída do console, então o prompt de senha vai para stdout: "git @ what's password:". Isso é visto pelo git como uma saída de protocolo corrompida.
Ed Avis

Obrigado @EdAvis! Eu tive o mesmo problema e depois de ler seu comentário, verifiquei duas vezes meu agente principal (que geralmente é executado na inicialização da minha máquina). Acontece que não estava funcionando por algum motivo ...
Griddo

5

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

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

A resolução para mim inclui as etapas abaixo:

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

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


4
Nota: Isso ocorre porque você está usando o plink e, se o fizer plink <server_name> ls, a primeira coisa que o plink imprime no stdout é login asque o git parece estar tentando interpretar como algo importante. Uma solução rápida é simplesmente unset GIT_SSHe unset SVN_SSH. Mais informações aqui
Pod

@Pod você está certo, no windows estes comandos devem ajudar: set GIT_SSH=eset SVN_SSH=
Maksim Kostromin

Tive o mesmo problema com o TFS. Depois de adicionar a ID da chave, tudo funciona bem, obrigado!
Andre Hofmeister


3

Verifique seus arquivos de inicialização na conta usada para se conectar à máquina remota em busca de declarações "echo". Para o shell do Bash, seriam seu .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 padrão ao fazer login em um servidor via ssh. O Git obterá os primeiros quatro bytes desse boiler-plate e gerará este erro. Agora, neste caso específico, vou supor que "Unab" é na verdade o trabalho "Incapaz de ...", o que provavelmente indica que há algo mais errado no host Git.


3

No meu caso, depois buscá-la foi escrito: fatal: protocol error: bad line length character: Pass. Além disso, depois de empurrar, obtive:fatal: protocol error: bad line length character: git@ Done .

Após reiniciar o Windows, tive que iniciar o "agente PuTTY" (pageant.exe) novamente e adicionar uma chave privada que desapareceu de uma lista de chaves.


2

Para sua informação, recebi a mesma mensagem de erro depois de atualizar um contêiner CentOS6 para CentOS7 - algumas operações git começaram a falhar durante a construção do contêiner, por exemplo

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

A execução de ssh me deu um erro que 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 tinha um LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1em um Dockerfile pai. Comentar isso corrigiu o erro.


2

No meu caso, o problema era o Putty de 32 bits e o pageant.exe - ele não consegue 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.


2

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


1

Eu tive o mesmo problema que Christer Fernstrom. No meu caso, foi uma mensagem que coloquei em meu .bashrc que me lembra de fazer um backup quando não fizer um há alguns dias.


1

O seguinte pode ajudar alguém: Ao tentar clonar um projeto que tenho em minha instância do AWS EC2, estava recebendo 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 do git ... você verá a mensagem de erro em algo parecido com "Por favor, faça o login com o usuário ec2" Uma vez que eu fiz um clone do git como um usuário ec2, foi bom.


1

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


1

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

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 a ~ / .ssh / authorized_keys ou ~ / .ssh / authorized_keys2

Tive que lutar um pouco para fornecer uma chave privada para o Git Bash na máquina Windows. A resposta de Dan McClain em /server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 descreve isso. Um acréscimo à sua resposta, no meu caso, esperava-se que o arquivo de chave privada fosse nomeado id_rsa.pub


1

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


1

Se você usar Putty. Em seguida, certifique-se de que o Pageant está em execução e que sua chave privada está carregada no Pageant (clique com o botão direito do mouse no ícone do Pageant na barra de tarefas e clique em "Exibir chaves" no menu que aparece).

Caso contrário, quando você fizer em cmd.exe:

git clone ssh://name@host:/path/to/git/repo.git

você recebe esta mensagem "fatal: erro de protocolo: caractere de comprimento de linha inválido:"


1

TL; DR: Do não omitir username@em suas URLs remotas quando no Windows.

No Linux e no Windows com o ssh padrão, você pode omitir o nome de usuário de URLs remotos, assim:

git clone server-name:/srv/git/repo-name

Porque o comportamento padrão do ssh é apenas usar qualquer nome de usuário com o qual você esteja conectado no momento. Se você estiver no Windows e tiver configurado o git para usar de plink.exeforma que possa usar a chave carregada em seu pageant, isso não funcionará, porque plinknão tem esse mesmo comportamento de nome de usuário automático, resultando nessas mensagens de erro enigmáticas, porque funcionará solicitar o nome de usuário:

$ plink server-name
login as: _

Versus:

$ plink username@server-name
...logs you in...

Se você já clonou um repositório de alguma forma, pode consertar os controles remotos em seu .git/configadicionando o username@ao URL remoto.


Adicionar nome de usuário ao remoto por git remote set-url origin myusername@...me ajudou.
Maxim Suslov

0

Verifique se o acesso ao Shell é permitido no servidor.


o meu era "Hi g". Acontece que eu segui algum site de configuração de segurança e agora meu login git diz "Olá git! Você autenticou com sucesso, mas eu não forneço acesso ao shell interativo.". acho que terei que remover isso ....
brilhante

0

O erro se transformou em: fatal: erro de protocolo: caractere de comprimento de linha inválido: fata

depois de adicionar a localização de git-upload-pack ao caminho do sistema.

O problema parece ser um apóstrofo adicionado em torno do nome do repositório: Procurando com uma ferramenta como o Process Monitor (de internos sys), que foram adicionados pelo cliente git. Parece ser um problema específico do Windows do git.

Eu tentei a mesma linha de comando no prompt do servidor: o erro completo foi "fatal: não é um repositório fornecido (ou qualquer um dos diretórios pais): .git"

Concluindo, para mim parece um bug de software. Esteja ciente de que não sou um especialista em git, é a primeira vez que uso o git, venho do subversion e forçosamente.


0

Nós corremos para 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

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


0

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


0

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


0

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


0

Resposta tardia aqui, mas espero que ajude alguém. Se for um erro de protocolo, ele tem que fazer algo com seu git local e não consegue se comunicar com o git remoto. Isso pode acontecer se você clonou o repo via ssh e algum tempo depois, você perdeu as chaves para o repo ou seu agente ssh não consegue mais encontrar essas chaves.

Solução

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

  2. Outra solução rápida é ir para o seu .gitdiretório e editar o configarquivo [remote "origin"] urlde gitpara httppara que as chaves ssh não sejam necessárias para enviar e voltará a 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/*

0

Alterar o ssh exectuable de embutido para nativ em settings / version control / git fez o truque para mim.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.