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

J'ai configuré un serveur git et je veux maintenant pousser initialement mon dépôt depuis le client. J'ai utilisé git push origin masteret j'obtiens 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.

J'ai configuré le serveur avec "authorised_keys" et SSH. (Je peux me connecter, en utilisant SSH.)

Cela semble être un problème 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 avec une réponse git appropriée. En fin de compte, il y a eu un problème sur le serveur exécutant le git-receive-packprocessus.

Dans le protocole Git, les quatre premiers octets doivent correspondre à la longueur de la ligne. Au lieu de cela, c'étaient les personnages Unab... ce qui est probablement le début d'un message d'erreur quelconque. (c'est-à-dire, c'est probablement " Unable to..." faire quelque chose).

Que se passe-t-il lorsque vous courez ssh <host> git-receive-pack <path-to-git-repository>? Vous devriez voir le message d'erreur sur lequel votre client git barfing 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 dans Windows, avec GIT_SSHle chemin d'accès plink.exede PuTTY.

Problèmes et solutions possibles:

• Assurez-vous que le chemin vers plink.exeest 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 de clé contient une clé valide pour accéder au serveur

Pour les utilisateurs de GitExtension:

J'ai rencontré le même problème après la mise à niveau de git vers la version 2.19.0

Solution:

Outils> Paramètres> Extensions Git> SSH

Sélectionnez [ OpenSSH ] au lieu de [ PuTTY ]

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 qu'après le redémarrage, le 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 ajouter à nouveau la clé, et cela a bien fonctionné. Donc, dans ce cas, il est nécessaire de faire en sorte que pagenant charge automatiquement la clé, comme indiqué ici:

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

Peut-être avez-vous une instruction dans le fichier .bashrc du serveur qui produit une sortie. Moi, par exemple, j'avais 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 les extensions Git, ce problème est résolu.

Vous pouvez rediriger n'importe quelle sortie de .bashrcvers stderr:

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

git ignorera ces symboles

J'ai eu un problème similaire sur Windows en utilisant Git Bash. J'ai continué à recevoir cette erreur en essayant de faire un clone 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 était générée. La clé publique a été ajoutée sur GitLab. L'agent ssh était en cours d'exécution et la clé générée a été ajoutée ( lien github ).

J'ai manqué d'options, puis j'ai finalement essayé de fermer Git Bash et de l'ouvrir à nouveau en cliquant avec le bouton droit sur «Exécuter en tant qu'administrateur». A travaillé après ça.

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 ci-dessous:

1. Assurez-vous que la clé SSH (publique) est ajoutée / mise à jour dans l'instance EC2.
2. Assurez-vous que l'agent d'authentification (dans mon cas, son agent d'authentification Pageant = Putty) 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 pour git clone. Exemple:

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

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

RequestTTY force

dans .ssh / config

commenter cela lui a permis de fonctionner

Vérifiez vos fichiers de démarrage sur le compte utilisé pour se connecter à la machine distante pour les instructions "echo". Pour le shell Bash, ce serait votre .bashrc et .bash_profile, etc. Edward Thomson a raison dans sa réponse, mais un problème spécifique que j'ai rencontré est quand il y a une impression passe-partout lors de la connexion à un serveur via ssh. Git obtiendra les quatre premiers octets de cette plaque chauffante et lèvera 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.

Dans mon cas , après avoir été chercher écrit: fatal: protocol error: bad line length character: Pass. De plus , après pression , je suis arrivé: fatal: protocol error: bad line length character: git@ Done.

Après le redémarrage de Windows, j'ai dû redémarrer "PuTTY agent" (pageant.exe) et ajouter une clé privée qui disparaissait d'une liste de clés.

Pour info, j'ai reçu ce même message d'erreur après avoir mis à niveau un conteneur CentOS6 vers CentOS7 - certaines opérations git ont commencé à échouer lors de la construction 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 git@bitbucket.org
Invalid clock_id for clock_gettime: 7

Cela m'a conduit à 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.1fichier Dockerfile parent. Commenter cela a corrigé l'erreur.

Dans mon cas, le problème était Putty 32 bits 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.

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

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 qui me rappelle de faire une sauvegarde quand je n'en ai pas fait une depuis quelques jours.

Ce qui suit peut aider quelqu'un: Lorsque j'essayais de cloner un projet que j'ai sur mon instance AWS EC2, j'obtenais 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 d'EC2-USER. si vous faites réellement ssh sans faire un clone git ... vous verrez le message d'erreur dans quelque chose comme "Veuillez vous connecter avec ec2-user" Une fois que j'ai fait un clone git en tant qu'utilisateur ec2, c'était bien.

Je rencontre également cette erreur de temps en temps, mais quand c'est le cas, cela signifie que ma succursale n'est pas à jour, alors je dois le faire git pull origin <current_branch>

Git ne demande pas de mot de passe et échoue avec un message cryptique similaire "fatal: erreur de protocole: caractère de longueur de ligne incorrecte: 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 la clé publique sur le serveur. Ajoutez simplement la clé publique à ~ / .ssh / allowed_keys ou ~ / .ssh / allowed_keys2

J'ai eu un peu de mal à fournir une clé privée au Git Bash sur la machine Windows. La réponse de Dan McClain dans /server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 décrit cela. Un ajout à sa réponse, dans mon cas, le fichier de clé privée devait être nommé id_rsa.pub

Pour moi, ajouter les 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.

Si vous utilisez Putty. Ensuite, assurez-vous que Pageant est en cours d'exécution et que votre clé privée est chargée dans Pageant (cliquez avec le bouton droit de la souris sur l'icône Pageant dans la barre des tâches et cliquez sur "Afficher les clés" dans le menu qui apparaît).

Sinon, lorsque vous faites dans cmd.exe:

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

vous obtenez ce message "fatal: erreur de protocole: caractère de longueur de ligne incorrect:"

TL; DR: Ne pas omettre username@dans vos URL à distance lorsque sous Windows.

Sous Linux et sous Windows avec le ssh par défaut, vous pouvez omettre le nom d'utilisateur des URL distantes, comme ceci:

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

Parce que le comportement par défaut de ssh est d'utiliser simplement le nom d'utilisateur avec lequel vous êtes actuellement connecté. Si vous êtes sous Windows et que vous avez configuré git pour l'utiliser plink.exeafin que vous puissiez utiliser la clé chargée dans votre pageant, cela ne fonctionnera pas, car il plinkn'a pas le même comportement de nom d'utilisateur automatique, ce qui entraîne ces messages d'erreur cryptiques, car cela demander le nom d'utilisateur:

$ plink server-name
login as: _

Contre:

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

Si vous avez déjà cloné un référentiel d'une manière ou d'une autre, vous pouvez réparer les télécommandes de votre .git/configen ajoutant le username@à l'URL distante.

Vérifiez si l'accès Shell est autorisé sur le serveur.

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

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

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

J'ai essayé la même ligne de commande dans l'invite du serveur: l'erreur complète était "fatale: pas un référentiel donné (ou l'un des répertoires parents): .git"

En conclusion, cela me semble être 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 forcément.

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 gitty sur ce qui n'a pas fonctionné, mais dans notre cas, ce qui l'a déclenché, c'est que le disque sur le serveur était plein.

Cela pourrait être un accès de sécurité sur votre machine, utilisez-vous Pageant (qui est un agent de mastic)?

vous pouvez toujours avoir un lien http vers votre projet git. Vous pouvez utiliser cela 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 le 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 la connexion avec RSA en même temps ...

Réponse tardive ici, mais j'espère que cela aidera quelqu'un. Si c'est 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 repo via ssh et que plus tard, vous avez perdu les clés du repo ou si votre agent ssh ne peut plus trouver ces clés.

Solution

1. Générez une nouvelle clé et ajoutez-la à votre repo git ou configurez votre agent ssh pour charger les clés si vous avez toujours les clés avec vous et pas avec quelqu'un d'autre;)

2. Une autre solution rapide consiste à aller dans votre .gitrépertoire et à modifier le configfichier [remote "origin"] urlde gità httpafin que les clés ssh ne soient pas nécessaires pour pousser et il reviendra à vous demander votre nom d'utilisateur et votre 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 exécutable de builtin à nativ sous settings / version control / git a fait l'affaire pour moi.