Git Remote: Erreur: fatale: erreur de protocole: caractère de longueur de ligne incorrect: Unab

J’ai mis en place un serveur git et je veux maintenant pousser d’abord mon repository depuis le client. J’ai utilisé git push origin master et reçois ce message d’erreur:

 fatal: protocol error: bad line length character: Unab 

Je ne sais pas ce qui ne va pas. Je ne sais pas ce qu’est “Unab”. J’ai essayé de redimensionner le shell mais c’est toujours “Unab”. Je ne trouve pas de solution pour ce message d’erreur.

Je configure le serveur avec “authorized_keys” et SSH. (Je peux me connecter en utilisant SSH.)

Cela semble être un problème de git?

BTW: le serveur est configuré dans une machine virtuelle Windows 7

Ce message d’erreur est un peu obtus, mais ce qu’il essaie de vous dire, c’est que le serveur distant n’a pas répondu correctement. En fin de compte, il y avait un problème sur le serveur exécutant le processus git-receive-pack .

Dans le protocole Git, les quatre premiers octets doivent correspondre à la longueur de la ligne. Au lieu de cela, ils étaient les caractères Unab … qui est probablement le début d’un message d’erreur quelconque. (c’est-à-dire qu’il est probablement Unable to... faire quelque chose).

Que se passe-t-il lorsque vous exécutez ssh git-receive-pack ? Vous devriez voir le message d’erreur que votre client git est en train de faire et vous pourrez peut-être le corriger.

J’ai eu un problème similaire, mais le message d’erreur exact était:

fatal: erreur de protocole: caractère de longueur de ligne incorrect: Usin

Ceci est sous Windows, avec GIT_SSH défini sur le chemin de plink.exe de PuTTY.

Problèmes possibles et solutions:

  • Assurez-vous que le chemin d’access à plink.exe est correct. Le chemin de style Unix fonctionne bien aussi, par exemple /c/work/tools/PuTTY/plink.exe
  • Assurez-vous que l’agent clé de PuTTY ( pageant.exe ) est en cours d’exécution
  • Assurez-vous que l’agent clé contient une clé valide pour accéder au serveur

Peut-être que vous avez une déclaration dans le fichier .bashrc du serveur qui produit une sortie. J’ai par exemple eu ceci:

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

Dans ce cas, la sortie de l’utilisation de rvm sera (à tort) interprétée comme provenant de git. Alors remplacez-le par:

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

Après avoir chargé la clé privée SSH dans Git Extensions, ce problème est résolu.

J’ai eu le même genre de problème après l’installation de GIT sur Windows. Au début cela a fonctionné; puis, un jour plus tard (après un redémarrage du PC), ce n’était plus le cas, et j’ai eu ceci:

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

Le problème était que, après le redémarrage, Putty “pageant.exe” démarré automatiquement n’avait plus la clé privée active. Lorsque vous ajoutez une clé dans pageant, ce n’est pas un paramètre persistant par défaut. Je devais juste rappend la clé, et ça marchait bien. Donc, pour ce cas, il est nécessaire de faire en sorte que pagenant charge la clé automatiquement, comme indiqué ici:

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

Vous pouvez redirect n’importe quelle sortie de .bashrc vers stderr :

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

git va ignorer ces symboles

J’ai eu un problème similaire sous Windows en utilisant Git Bash. J’ai continué à avoir cette erreur en essayant de faire un clone de git. Le référentiel était sur une machine Linux avec GitLab installé.

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

Je me suis assuré que la clé ssh avait été générée. La clé publique a été ajoutée sur GitLab. Le ssh-agent était en cours d’exécution et la clé générée a été ajoutée ( lien github ).

Je n’ai plus eu d’options et j’ai finalement essayé de fermer Git Bash et de l’ouvrir à nouveau en cliquant avec le bouton droit de la souris sur «Exécuter en tant qu’administrateur». A travaillé après ça.

Vérifiez vos fichiers de démarrage sur le compte utilisé pour vous connecter à la machine distante pour les instructions “echo”. Pour le shell Bash, il s’agirait de votre fichier .bashrc et .bash_profile, etc. Edward Thomson a raison dans sa réponse, mais un problème spécifique est survenu lors d’une impression sur le serveur lors de la connexion à un serveur via ssh. Git récupérera les quatre premiers octets de cette plaque chauffante et déclenchera cette erreur. Maintenant, dans ce cas précis, je vais deviner que “Unab” est en fait le travail “Unable …” qui indique probablement qu’il y a autre chose qui ne va pas sur l’hôte Git.

Pour moi c’était parce que j’ai récemment ajouté

 RequestTTY force 

dans .ssh / config

commenter cela a permis de travailler

Cela pourrait aider quelqu’un. Lorsque j’essayais de cloner un projet à partir d’une instance EC2, j’obtenais l’erreur ci-dessous:

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

La résolution pour moi comprend les étapes suivantes:

  1. Assurez-vous que la clé SSH (public) est ajoutée / mise à jour dans l’instance EC2.
  2. Assurez-vous que l’agent d’authentification (dans mon cas, son Pageant = Putty Authentication Agent) est en cours d’exécution et que la clé privée correspondante est chargée.
  3. Utilisez l’ID de clé SSH EC2 pour la clé publique du clone git. Exemple:

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

Dans mon cas, après la recherche, il a été écrit: fatal: protocol error: bad line length character: Pass . Aussi après la poussée, j’ai: fatal: protocol error: bad line length character: git@ Done .

Après le redémarrage de Windows, j’ai dû redémarrer “agent PuTTY” (pageant.exe) et append une clé privée qui disparaît de la liste des clés.

L’erreur transformée en: fatal: erreur de protocole: caractère de longueur de ligne incorrect: fata

après avoir ajouté l’emplacement de git-upload-pack au chemin du système.

Le problème semble être une apostrophe ajoutée autour du nom du référentiel: avec un outil comme Process Monitor (à partir de sys internals), ajouté par le client git. Cela semble être un problème Windows spécifique à git.

J’ai essayé la même ligne de commande à l’invite du serveur: l’erreur complète était “fatal: pas un référentiel donné (ou aucun des répertoires parents): .git”

En conclusion, pour moi, cela ressemble à un bug logiciel. Sachez que je ne suis pas un expert git, c’est la première fois que j’utilise git, je viens de subversion et forforce.

J’ai eu le même problème que Christer Fernstrom. Dans mon cas, c’était un message que j’avais mis dans mon .bashrc et qui me rappelait de faire une sauvegarde quand je ne l’ai pas fait dans quelques jours.

Ce qui suit peut aider quelqu’un: En essayant de cloner un projet que j’ai sur mon instance AWS EC2, j’obtiens l’erreur suivante:

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

Cela a été causé en essayant de ssh en tant que root au lieu de EC2-USER. Si vous avez réellement ssh sans faire un clone de git … vous verrez le message d’erreur dans quelque chose du genre “Veuillez vous connecter avec ec2-user” Une fois que j’ai fait un clone de git en tant qu’utilisateur ec2, c’était bien.

Je rencontre également cette erreur de temps en temps, mais lorsque cela se produit, cela signifie que ma twig n’est pas à jour. Je dois donc faire git pull origin

FYI J’ai reçu le même message d’erreur après la mise à niveau d’un conteneur CentOS6 vers CentOS7 – certaines opérations git ont échoué lors de la création du conteneur, par exemple

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

L’exécution de ssh m’a donné une erreur sur laquelle je pouvais rechercher:

 # ssh [email protected] Invalid clock_id for clock_gettime: 7 

Cela m’a amené à https://github.com/wolfcw/libfaketime/issues/63 où j’ai réalisé que j’avais oublié que j’avais un LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 dans un fichier Dockerfile parent. Commentant que corrigé l’erreur.

Pour moi, l’ajout des mêmes détails d’hôte dans Putty avec la clé privée (convertir avec puttygen) a fonctionné. Toutes les commandes git bash après cela n’ont eu aucun problème.

J’ai eu la même erreur "fatal: protocol error: bad line length character: shmi" Où le shmi est le nom d’utilisateur dans mon cas. J’ai changé SSH de PuTTY à OpenSSH dans "Git Extensions->Settings->SSH" . Ça m’a aidé.

Nous avons rencontré cela aussi.

 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 

Je ne connais pas les détails précis sur ce qui a mal tourné, mais dans notre cas, ce qui a déclenché la situation était que le disque sur le serveur était plein.

Cela pourrait être un access de sécurité sur votre machine, exécutez-vous Pageant (qui est un agent de mastic)?

vous pouvez toujours avoir un lien http vers votre projet git. Vous pouvez l’utiliser au lieu du lien ssh. Ceci est juste une option que vous avez

Eh bien, j’ai eu ce même problème (Windows 7). Essayez d’obtenir un repo par mot de passe. J’utilise Git Bash + Plink (variable d’environnement GIT_SSH) + Pageant. La suppression de GIT_SSH (temporaire) m’aide. Je ne sais pas pourquoi je ne peux pas utiliser la connexion par passe et me connecter avec RSA en même temps …

Dans mon cas, le problème était 32-bit Putty et pageant.exe – il ne peut pas communiquer avec TortoisePlink.exe 64 bits. Le remplacement de Putty 32 bits par une version 64 bits a résolu le problème.

Git ne demande pas de mot de passe et échoue avec un message crypté similaire “fatal: erreur de protocole: caractère de longueur de ligne incorrect: utilisateur” si vous ne disposez pas également de votre configuration d’authentification par clé privée .

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server indique comment spécifier une clé publique sur le serveur. Ajouter la clé publique à ~ / .ssh / authorized_keys ou ~ / .ssh / authorized_keys2

J’ai dû me débattre un peu sur la manière de fournir une clé privée au Git Bash sur la machine Windows. La réponse de Dan McClain dans https://serverfault.com/questions/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 le décrit. Un ajout à sa réponse, dans mon cas, le fichier de clé privée devait être nommé id_rsa.pub

Réponse tardive ici, mais espérons que cela aidera quelqu’un. S’il s’agit d’une erreur de protocole, il doit faire quelque chose avec votre git local incapable de communiquer avec le git distant. Cela peut arriver si vous avez cloné le repository via ssh et plus tard, vous avez perdu les clés du repository ou votre agent ssh ne peut plus trouver ces clés.

Solution

  1. Générez une nouvelle clé et ajoutez-la à votre repository git ou configurez votre agent ssh pour qu’il charge les clés si vous avez toujours les clés avec vous et non avec quelqu’un d’autre;)

  2. Une autre solution rapide consiste à aller dans votre répertoire .git et à modifier l’ [remote "origin"] url du fichier de config de git à http afin que les clés ssh ne soient pas nécessaires pour pousser et que vous retourniez à votre nom d’utilisateur et mot de passe.

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

Changer pour

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

Changer le ssh exquisable de incorporé en nativ sous parameters / contrôle de version / git a fait l’affaire pour moi.

Vérifiez si l’access au shell est autorisé sur le serveur.