Git Remote: Erreur: fatal: erreur de protocole: mauvaise longueur de la ligne de caractère: Unab

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

fatal: erreur de protocole: mauvaise longueur de la ligne de caractère: Usin

C'est dans Windows, avec GIT_SSH mis au chemin de plink.exe de mastic.

problèmes et solutions possibles:

• assurez-vous que le chemin vers plink.exe est correct. Le chemin de style Unix fonctionne aussi bien, 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 serveur .bashrc qui produit des résultats. J'ai, par exemple, a 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 rvm sera (à tort) interprétée comme provenant de git. Ainsi le remplacer 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.

j'ai eu le même genre de problème après avoir installé GIT sur Windows. Au début, ça a fonctionné; puis, un jour plus tard (après un redémarrage de PC), ça n'a plus marché, et j'ai eu ça:

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

le problème était qu'après le redémarrage, le concours de mastic a commencé automatiquement.exe n'avait plus la clé privée active. Quand vous ajoutez une clé dans le concours, ce n'est pas un paramètre persistant par défaut. J'ai encore dû rajouter la clé, et ça a bien marché. Donc, pour ce cas, il est nécessaire pour faire charger la clé pagenant automatiquement, comme discuté ici:

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

vous pouvez rediriger n'importe quelle sortie de .bashrc à 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 toujours eu cette erreur en essayant de faire un clone git. Le dépôt était sur une machine Linux avec GitLab installé.

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

j'ai fait en sorte que la clé ssh soit 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 ( GitHub link ).

Je n'avais plus le choix et j'ai finalement essayé de fermer Git Bash et de l'ouvrir de nouveau par un clic droit "Exécuter en tant qu'Administrateur". Travaillé par la suite.

Vérifiez vos fichiers de démarrage sur le compte utilisé pour vous connecter à la machine distante pour les déclarations" echo". Pour le bash shell, ce sont les vôtres .bashrc et .bash_profile etc. Edward Thomson a raison dans sa réponse, mais un problème spécifique que j'ai éprouvé est quand il ya une impression chaudière-plaque lors de la connexion à un serveur via SSH. Git va obtenir les quatre premiers octets de cette plaque chauffante et augmenter cette erreur. Maintenant, dans ce cas précis, je vais deviner que "Unab" est en fait le travail "Impossible..."ce qui indique probablement qu'il y a quelque chose d'autre qui ne va pas sur l'hôte Git.

pour moi, c'est parce que j'ai récemment ajouté

RequestTTY force

vers .SSH / config

commentant ceci a permis à cela de fonctionner

Cela pourrait aider quelqu'un. Quand j'ai essayé de cloner un projet à partir D'une instance EC2, j'ai eu l'erreur suivante:

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

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

1. S'assurer que la clé SSH (publique) est ajoutée/mise à jour dans L'instance EC2.
2. S'assurer que l'agent d'authentification (dans mon cas son concours=Putty Authentication Agent) est en cours d'exécution et que la clé privée correspondante est chargée.

3. utilisez la clé EC2 SSH ID pour la clé publique pour le clone git. Exemple:

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

dans mon cas après fetch il a été écrit: fatal: protocol error: bad line length character: Pass . Aussi après push j'ai eu: fatal: protocol error: bad line length character: git@ Done .

après le redémarrage de Windows j'ai dû lancer "PuTTY agent" (concours.exe) et ajouter une clé privée qui a disparu à partir d'une liste de clés.

l'erreur transformée en: fatal: erreur de protocole: mauvaise longueur de ligne caractère: 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 dépôt: regarder avec un outil comme Process Monitor (de sys internals), qui ont été ajoutés par le client Git. Il semble être un git spécifiques de problème windows.

j'ai essayé la même ligne de commande dans le invite du serveur: le message d'erreur est "fatal: un référentiel (ou l'un des répertoires parents): .git "

en conclusion, pour moi ça ressemble à un bug logiciel. Sachez que je ne suis pas un git expert, c'est la première fois que j'utilise git, je viens de subversion et de perforce.

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

ce qui suit peut aider quelqu'un: En essayant de cloner un projet que j'ai sur mon instance AWS EC2 j'ai eu l'erreur suivante:

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

cela a été causé en essayant de ssh comme root au lieu de EC2-USER. si vous faites SSH sans faire un clone git... vous verrez l'Erreur msg dans quelque chose du genre "s'il vous plaît connectez-vous avec ec2-user" Une fois que j'ai fait un clone git en tant qu'utilisateur ec2, c'était bien.

je rencontre aussi cette erreur de temps en temps, mais quand elle le fait, cela signifie que ma branche n'est pas à jour donc je dois faire git pull origin <current_branch>

FYI j'ai reçu ce même message d'erreur après avoir mis à niveau un conteneur CentOS6 en 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

exécuter ssh m'a donné une erreur que je pouvais rechercher sur:

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

qui 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.1 dans un Fichier parent Dockerfile. Commentant que fixe le erreur.

dans mon cas, le problème était un Putty 32-bit et un concours de beauté.exe-il ne peut pas communiquer avec 64-bit TortoisePlink.EXE. Remplacer 32-bit Putty par une version 64-bit a résolu le problème.

pour moi ajoutant les mêmes détails de l'hôte dans le mastic avec la clé privée (convertir avec puttygen) travaillé. Aucune commande de git bash après ça n'a eu de problème.

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

on a rencontré ça 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 sais pas les détails de gitty sur ce qui a mal tourné, mais dans notre cas ce qui a déclenché c'était que le disque sur le serveur était plein.

ça pourrait être un accès de sécurité sur votre machine, êtes-vous en train de diriger un concours (qui est un agent putty)?

vous pouvez toujours avoir un lien http vers votre projet git. Vous pouvez utiliser cela à la place du lien ssh. C'est juste une option que vous avez

Eh bien, j'ai eu ce même problème (Windows 7). Essayez d'obtenir des pensions par mot de passe. J'utilise Gitbash + Plink (variable D'environnement GIT_SSH) + Pageant. Supprimer GIT_SSH (temporaire) m'aide. Je ne sais pas pourquoi je ne peux pas utiliser login by pass et login avec RSA en même temps...

Git ne demande pas de mot de passe et échoue avec un message cryptique similaire" fatal: protocol error: bad line length character: user " si vous n'avez pas votre configuration d'authentification de clé privée aussi.

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. Fondamentalement, ajouter la clé publique à ~ / .ssh/authorized_keys ou ~/.ssh / authorized_keys2

j'ai dû lutter un peu sur la façon de fournir la clé privée de la Bash Git sur la machine windows. 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 décrit cela. En plus de sa réponse, dans mon cas, le fichier de clés privées devait s'appeler id_rsa.pub

réponse tardive ici, mais espérons que cela aidera quelqu'un. Si c'est une erreur de protocole, il doit faire quelque chose avec votre git local qui n'est pas capable de communiquer avec le Git distant. Cela peut se produire si vous avez cloné le repo via ssh et un peu plus tard, vous avez perdu les clés du repo ou votre agent ssh ne peut plus trouver ces clés.

Solution

1. Générer une nouvelle clé et ajouter votre repo git ou configurer votre agent ssh pour charger le les touches si vous avez encore les clés avec vous et pas avec quelqu'un d'autre ;)

2. une autre solution rapide est d'aller dans votre répertoire .git et d'éditer le fichier config de [remote "origin"] url de git à http de sorte que les touches ssh ne sont pas nécessaires pour pousser et il reviendra à demander votre nom d'utilisateur et votre mot de passe.

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

changement à

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

changer l'exécutable SSH de builtin à nativ sous Paramètres / Contrôle de version / git a fait l'affaire pour moi.

pour les utilisateurs de GitExtension:

j'ai connu le même problème après la mise à niveau de git pour 2.19.0

Solution:

Tools > Settings > Git Extensions > SSH

sélectionner [ OpenSSH ] au lieu de [ PuTTY ]

vérifiez si L'accès à L'interpréteur de commandes est autorisé sur le serveur.