Git Remote: Erreur: irrécupérable: Erreur de protocole: caractère de longueur de ligne incorrecte: Unab
J'ai mis en place un serveur git et je souhaite maintenant commencer par envoyer mon référentiel du client . J'ai utilisé git Push Origin master et je reçois le message d'erreur suivant:
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 il reste "Unab" . Je ne trouve pas de solution à ce message d'erreur.
J'ai installé le serveur avec "registered_keys" et SSH. (Je peux me connecter avec SSH.)
Cela semble être un problème de git?
BTW: le serveur est configuré sur une machine virtuelle Windows 7
Ce message d'erreur est un peu obtus, mais ce que l'on 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 avait un problème sur le serveur exécutant le processus git-receive-pack.
Dans le protocole Git, les quatre premiers octets devraient être la longueur de la ligne. Au lieu de cela, ils étaient les caractères Unab... qui est probablement le début un message d'erreur de quelque sorte. (c'est-à-dire que c'est probablement "Unable to..." faire quelque chose).
Que se passe-t-il lorsque vous exécutez ssh <Host> git-receive-pack <path-to-git-repository>? Vous devriez voir le message d'erreur que votre client git lance et vous pourrez peut-être le corriger.
J'ai eu le même problème, 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'accès à
plink.exeest correct. Le chemin de style Unix fonctionne aussi très bien, par exemple/c/work/tools/PuTTY/plink.exe - Assurez-vous que l'agent de 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.
Peut-être que vous avez une déclaration dans le fichier .bashrc du serveur qui produit une sortie. Par exemple, j'ai 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
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’est 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, la clé privée PuTTY "pageant.exe" démarrée automatiquement ne fonctionnait plus. Lorsque vous ajoutez une clé dans pageant, ce n'est pas un paramètre persistant par défaut. Il me suffisait de rajouter la clé et tout fonctionnait bien. Donc, dans ce cas, il est nécessaire de charger automatiquement la clé pagenant, comme indiqué ici:
Après avoir chargé la clé privée SSH dans Git Extensions, ce problème est résolu.
Vous pouvez rediriger toute sortie de .bashrc vers stderr:
# inside .bashrc
echo 'some error/warning/remind message' 1>&2
git ignorera ces symboles
J'ai eu un problème similaire sur Windows avec Git Bash. J'ai continué à avoir 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. Ssh-agent était en cours d'exécution et la clé générée a été ajoutée ( github link ).
J'ai manqué 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 cela.
Pour les utilisateurs de GitExtension:
J'ai rencontré le même problème après la mise à jour de git vers la 2.19.0
Solution:
Outils> Paramètres> Extensions Git> SSH
Sélectionnez [OpenSSH] au lieu de [PuTTY]
Dans mon cas après la récupération, il était écrit: fatal: protocol error: bad line length character: Pass. Aussi après avoir poussé j'ai eu: 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 a disparu de la liste des clés.
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:
- Assurez-vous que la clé SSH (publique) est ajoutée/mise à jour dans l'instance EC2.
- Assurez-vous que l'agent d'authentification (dans son cas, son agent Pageant = PuTTY Authentication Agent) est en cours d'exécution et que la clé privée correspondante est chargée.
Utilisez l'ID de clé SSH EC2 pour la clé publique du clone git. 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
commentant cela a permis de travailler
Vérifiez vos fichiers de démarrage sur le compte utilisé pour vous connecter à la machine distante pour les instructions "echo". Pour le Bash Shell, il s’agirait des fichiers .bashrc et .bash_profile, etc. Edward Thomson a raison, mais un problème spécifique que j’ai rencontré est la présence d’une impression de plaque chauffante lors de la connexion à un serveur via ssh. Git obtiendra les quatre premiers octets de cette plaque de chaudière et lèvera 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 de mal sur l'hôte Git.
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ù la shmi est le nom d'utilisateur dans mon cas . J'ai changé SSH de PuTTY à OpenSSH dans "Git Extensions->Settings->SSH". Cela a aidé.
je rencontre aussi cette erreur de temps en temps, mais quand cela se produit, cela signifie que ma succursale n'est pas à jour, donc je dois faire git pull Origin <current_branch>
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.
Pour info, j'ai reçu le 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
Courir ssh m'a donné une erreur sur laquelle je pouvais effectuer une recherche:
# ssh [email protected]
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.1 dans un fichier Dockerfile parent. Commenter cela a corrigé l'erreur.
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 incorrect: utilisateur" si vous n'avez pas non plus la configuration de votre 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. En gros, ajoutez la clé publique à ~/.ssh/registered_keys ou ~/.ssh/allowed_keys2
J'ai du mal à trouver un moyen de fournir une clé privée à Git Bash 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. Un ajout à sa réponse, dans mon cas, le fichier de clé privée devait s'appeler id_rsa.pub
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 du système.
Le problème semble être une apostrophe ajoutée autour du nom du référentiel: rechercher avec un outil tel que Process Monitor (de sys internals), ajouté par le client git. Cela semble être un problème spécifique à Windows.
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é (ni aucun 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.
Les éléments suivants peuvent aider quelqu'un: Lorsque j'essayais de cloner un projet sur mon instance AWS EC2, l'erreur suivante apparaissait:
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 utilisez ssh sans faire un clone de git ... vous verrez l'erreur msg 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.
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 rappelait de faire une sauvegarde alors que je ne l’avais pas fait depuis quelques jours.
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 arriver si vous avez cloné le référentiel via ssh et qu'un peu plus tard, vous avez perdu les clés du référentiel ou votre agent ssh ne peut plus les trouver.
Solution
Générez une nouvelle clé et ajoutez-la à votre dépôt Git ou configurez votre agent SSH pour qu'il charge les clés si vous en avez encore les clés et non avec quelqu'un d'autre;)
Une autre solution consiste à accéder à votre répertoire
.gitet à modifier le[remote "Origin"] urldu fichierconfig, degitàhttp, de manière à ce que les clés ssh ne soient pas nécessaires à Push et que le nom d'utilisateur et votre mot de passe soient demandés.[remote "Origin"] url = git@gitlab.*****.com:****/****.git fetch = +refs/heads/*:refs/remotes/Origin/*
Changer en
[remote "Origin"]
url = http://gitlab.*****.com/****/****.git
fetch = +refs/heads/*:refs/remotes/Origin/*
TL; DR: Faites pas omettez username@ dans vos URL distantes sous Windows.
Sous Linux et Windows avec ssh par défaut, vous pouvez omettre le nom d'utilisateur des URL distantes, comme suit:
git clone server-name:/srv/git/repo-name
Le comportement par défaut de ssh consiste simplement à utiliser le nom d'utilisateur avec lequel vous êtes actuellement connecté. Si vous êtes sous Windows et avez configuré git pour utiliser plink.exe afin que vous puissiez utiliser la clé chargée dans votre pageant, cela ne fonctionnera pas, car plink ne l’a pas. même comportement de nom d'utilisateur automatique, ce qui entraîne ces messages d'erreur cryptiques, car il va 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 dans votre .git/config en ajoutant le username@ à l'URL distante.
vous pouvez toujours avoir un lien http vers votre projet git. Vous pouvez utiliser cela à la place du lien ssh. Ceci est juste une option que vous avez
Changer l'exécutable ssh de natif à nativ sous paramètres/contrôle de version/git a été l'affaire.
Cela pourrait être un accès de sécurité sur votre machine, utilisez-vous Pageant (qui est un agent PuTTY)?
Nous avons couru dans 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 de ce qui ne va pas, mais dans notre cas, c'est le disque qui était sur le serveur qui était plein.
Si vous utilisez PuTTY. Assurez-vous ensuite 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 s’ouvre).
Sinon, quand 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 incorrecte:"
Eh bien, j'ai eu le même problème (Windows 7). Essayez d’obtenir un dépôt par mot de passe .J’utilise Git Bash + Plink (variable d’environnement GIT_SSH) + Pageant . Supprimer GIT_SSH (temporaire) m’aide. Je ne sais pas pourquoi je ne peux pas utiliser login par pass et me connecter avec RSA en même temps ...