webentwicklung-frage-antwort-db.com.de

Git Remote: Fehler: Fatal: Protokollfehler: Zeichen für schlechte Leitungslänge: Unab

Ich habe einen Git-Server eingerichtet und möchte jetzt zunächst mein Repo vom Client aus pushen. Ich habe git Push Origin master verwendet und diese Fehlermeldung erhalten

fatal: protocol error: bad line length character: Unab

Ich weiss nicht, was falsch ist. Ich weiß nicht was "Unab" ist. Ich habe versucht, die Größe der Shell zu ändern, aber es ist immer noch "Unab" . Ich kann keine Lösung für diese Fehlermeldung finden.

Ich setze den Server mit "authorized_keys" und SSH ein. (Ich kann mich mit SSH verbinden.)

Es scheint ein Git-Problem zu sein?

BTW: Der Server ist in einer Windows 7-VM eingerichtet

88
user437899

Diese Fehlermeldung ist etwas unübersichtlich, aber es wird versucht, Ihnen zu sagen, dass der Remote-Server nicht mit einer richtigen Antwort von git geantwortet hat. Letztendlich gab es ein Problem auf dem Server, auf dem der git-receive-pack-Prozess ausgeführt wird.

Im Git-Protokoll sollten die ersten vier Bytes die Leitungslänge sein. Stattdessen handelt es sich um die Zeichen Unab..., bei denen wahrscheinlich eine Fehlernachricht anfängt. (dh es ist wahrscheinlich "Unable to..." etwas zu tun).

Was passiert, wenn Sie ssh <Host> git-receive-pack <path-to-git-repository> ausführen? Sie sollten die Fehlermeldung sehen, die Ihr Git-Client blockiert, und Sie können sie möglicherweise korrigieren.

94
Edward Thomson

Ich hatte ein ähnliches Problem, aber die genaue Fehlermeldung lautete:

fatal: Protokollfehler: Zeichen für schlechte Leitungslänge: Usin

Dies ist in Windows, wobei GIT_SSH auf den Pfad von plink.exe von PuTTY gesetzt ist.

Mögliche Probleme und Lösungen:

  • Stellen Sie sicher, dass der Pfad zu plink.exe korrekt ist. Der Pfad im Unix-Stil funktioniert auch gut, zum Beispiel /c/work/tools/PuTTY/plink.exe
  • Stellen Sie sicher, dass der Schlüsselagent von PuTTY (pageant.exe) ausgeführt wird
  • Stellen Sie sicher, dass der Schlüsselagent einen gültigen Schlüssel für den Zugriff auf den Server enthält
45
janos

Möglicherweise haben Sie eine Anweisung in der .bashrc des Servers, die eine Ausgabe erzeugt. Ich zum Beispiel hatte folgendes:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
rvm use [email protected]

In diesem Fall wird die Ausgabe von der Rvm-Verwendung (falsch) als von Git kommend interpretiert. Ersetze es also durch:

rvm use [email protected] > /dev/null
16

Ich hatte das gleiche Problem nach der Installation von GIT unter Windows. Zuerst hat es funktioniert; Dann, einen Tag später (nach einem Neustart des PCs), war dies nicht mehr der Fall, und ich bekam Folgendes:

$ git pull
fatal: protocol error: bad line length character: [email protected]

Das Problem war, dass nach dem Neustart der automatisch gestartete PuTTY "pageant.exe" den privaten Schlüssel nicht mehr aktiv hatte. Wenn Sie einen Schlüssel in pageant hinzufügen, ist dies standardmäßig keine dauerhafte Einstellung. Ich musste nur den Schlüssel noch einmal hinzufügen, und es hat gut funktioniert. Für diesen Fall ist es daher notwendig, den Schlüssel pagenant automatisch laden zu lassen, wie hier beschrieben:

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

14
MaeseDude

Nach dem Laden des privaten SSH-Schlüssels in Git Extensions wird dieses Problem behoben.

11

Sie können jede Ausgabe von .bashrc zu stderr umleiten:

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

git ignoriert diese symbole

9
user2288008

Ich hatte ein ähnliches Problem unter Windows mit Git Bash. Ich habe immer diese Fehlermeldung erhalten, als ich einen Git-Klon gemacht habe. Das Repository befand sich auf einer Linux-Box, auf der GitLab installiert war.

git clone [email protected]:path/to/repo
fatal: protocol error: bad line length character: [email protected]

Ich stellte sicher, dass der SSH-Schlüssel generiert wurde. Der öffentliche Schlüssel wurde in GitLab hinzugefügt. Der ssh-agent wurde ausgeführt und der generierte Schlüssel wurde hinzugefügt ( github link ).

Ich hatte keine Optionen mehr und versuchte schließlich, Git Bash zu schließen und erneut zu öffnen, indem Sie mit der rechten Maustaste auf "Als Administrator ausführen" klicken. Danach gearbeitet.

7
syclee

Für GitExtension-Benutzer:

Das gleiche Problem hatte ich nach dem Upgrade von git auf 2.19.0

Lösung:

Extras> Einstellungen> Git-Erweiterungen> SSH

Wählen Sie [OpenSSH] anstelle von [PuTTY]

 enter image description here

6
Amit Shah

In meinem Fall wurde nach dem Abrufen geschrieben: fatal: protocol error: bad line length character: Pass. Auch nach Push bekam ich: fatal: protocol error: bad line length character: [email protected] Done.

Nach dem Neustart von Windows musste ich "PuTTY agent" (pageant.exe) erneut starten und einen privaten Schlüssel hinzufügen, der aus einer Liste von Schlüsseln verschwunden ist.

3
CoolMind

Das könnte jemandem helfen. Beim Versuch, ein Projekt aus einer EC2-Instanz zu klonen, wurde die folgende Fehlermeldung angezeigt:

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

Die Auflösung beinhaltet für mich die folgenden Schritte:

  1. Stellen Sie sicher, dass der SSH-Schlüssel (öffentlich) in der EC2-Instanz hinzugefügt/aktualisiert wird.
  2. Stellen Sie sicher, dass der Authentifizierungsagent (in meinem Fall Pageant = PuTTY Authentication Agent) ausgeführt wird und der entsprechende private Schlüssel geladen wird.
  3. Verwenden Sie die EC2-SSH-Schlüssel-ID für den öffentlichen Schlüssel für git clone. Beispiel: 

    git clone ssh: // {SSH-Schlüssel-ID}@someaccount.amazonaws.com/v1/repos/repo1

3
acveer

Für mich war es, weil ich vor kurzem hinzugefügt habe 

RequestTTY force

in .ssh/config

dies zu kommentieren erlaubte es zu funktionieren

Überprüfen Sie Ihre Startdateien für das Konto, mit dem eine Verbindung zum Remote-Computer hergestellt wurde, auf "Echo" -Anweisungen. Für die Bash-Shell wären dies Ihre .bashrc und .bash_profile usw. Edward Thomson ist in seiner Antwort richtig, aber ein spezielles Problem, das ich erlebt habe, ist, wenn beim Anmelden an einen Server über ssh ein Kesselplattenausdruck vorliegt. Git erhält die ersten vier Bytes dieser Speicherplatte und gibt diesen Fehler aus. In diesem speziellen Fall werde ich vermuten, dass "Unab" eigentlich die Arbeit "Unable ..." ist, was wahrscheinlich darauf hinweist, dass auf dem Git-Host etwas anderes nicht stimmt.

3
snarkyname77

In meinem Fall war das Problem 32-Bit-PuTTY und pageant.exe - es kann nicht mit 64-Bit-TortoisePlink.exe kommuniziert werden. Das Ersetzen von 32-Bit-PuTTY durch eine 64-Bit-Version hat das Problem behoben.

2

Ich hatte den gleichen Fehler "fatal: protocol error: bad line length character: shmi" Wo shmi in meinem Fall der Benutzername ist . Ich habe SSH von PuTTY auf OpenSSH in "Git Extensions->Settings->SSH"..__ umgestellt.

2
Val

ich stoße auch gelegentlich auf diesen Fehler, aber wenn dies der Fall ist, bedeutet dies, dass mein Zweig nicht auf dem neuesten Stand ist, also muss ich git pull Origin <current_branch> tun.

1
bonbon.langes

Für mich hat das Hinzufügen der gleichen Host-Details in PuTTY mit dem privaten Schlüssel (convert with puttygen) funktioniert. Alle git bash-Befehle hatten danach keine Probleme.

1
David Aleu

Zu Ihrer Information Ich habe diese Fehlermeldung erhalten, nachdem ich einen CentOS6-Container auf CentOS7 aktualisiert habe. Einige git-Vorgänge sind beim Erstellen des Containers fehlgeschlagen, z.

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

Das Ausführen von ssh gab mir einen Fehler, nach dem ich suchen konnte:

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

Das führte mich zu https://github.com/wolfcw/libfaketime/issues/63 wo ich merkte, dass ich vergessen hatte, dass ich einen LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 in einer übergeordneten Docker-Datei hatte. Das Kommentieren beseitigte den Fehler.

1
jamshid

Git fordert nicht zur Eingabe eines Kennworts auf und schlägt mit einer ähnlichen kryptischen Nachricht fehl: "fatal: Protokollfehler: Zeichen für schlechte Leitungslänge: Benutzer" , wenn Sie nicht über eine private Schlüsselauthentifizierung verfügen.

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server gibt an, wie der öffentliche Schlüssel auf dem Server angegeben wird. Fügen Sie den öffentlichen Schlüssel grundsätzlich zu ~/.ssh/authorised_keys oder ~/.ssh/authorised_keys2 hinzu

Ich musste mich ein bisschen darum kümmern, wie man dem Git Bash auf der Windows-Maschine einen privaten Schlüssel zur Verfügung stellt. Dan McClains Antwort in https://serverfault.com/questions/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 beschreibt das. Ein Zusatz zu seiner Antwort: In meinem Fall sollte die private Schlüsseldatei id_rsa.pub heißen

1
Sandip

Der Fehler wurde umgewandelt in: Fatal: Protokollfehler: Zeichen für schlechte Leitungslänge: Fata

nachdem Sie den Speicherort von git-upload-pack zum Systempfad hinzugefügt haben.

Das Problem scheint ein Apostroph zu sein, der um den Namen des Repositorys hinzugefügt wurde: Suchen mit einem Tool wie Process Monitor (von sys internals), das vom git-Client hinzugefügt wurde. Es scheint ein git-spezifisches Windows-Problem zu sein.

Ich habe die gleiche Befehlszeile in der Eingabeaufforderung des Servers ausprobiert: Der vollständige Fehler war "fatal: kein gegebenes Repository (oder eines der übergeordneten Verzeichnisse): .git"

Zusammenfassend erscheint es mir wie ein Softwarefehler. Seien Sie darauf angewiesen, dass ich kein Git-Experte bin. Es ist das erste Mal, dass ich Git benutze. Ich komme aus Subversion und zwangsweise.

1
Razvan

Folgendes kann jemandem helfen: Beim Versuch, ein Projekt zu klonen, das ich in meiner AWS EC2-Instanz habe, wurde der folgende Fehler angezeigt: 

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

Dies wurde durch den Versuch verursacht, ssh als root anstelle von EC2-USER ..__ zu verwenden. Wenn Sie ssh tatsächlich ohne git-Klon machen ... wird der Fehler msg in der Zeile "Bitte anmelden mit ec2-user" angezeigt Nachdem ich als ec2-user einen git-Klon gemacht hatte, war es gut.

1
ConfusedDeer

Ich hatte das gleiche Problem wie Christer Fernstrom. In meinem Fall war es eine Nachricht, die ich in meine .bashrc gestellt hatte, die mich daran erinnert, ein Backup zu machen, wenn ich in ein paar Tagen keine gemacht habe. 

1

Späte Antwort hier, hoffe aber, dass es jemandem helfen wird. Wenn es sich um einen Protokollfehler handelt, hat dies etwas mit Ihrem lokalen Git zu tun, der nicht in der Lage ist, mit dem entfernten Git zu kommunizieren. Dies kann passieren, wenn Sie das Repo über ssh geklont haben und später die Schlüssel für das Repo verloren haben oder Ihr ssh-Agent diese Schlüssel nicht mehr finden kann. 

Lösung

  1. Erzeugen Sie einen neuen Schlüssel und fügen Sie ihn Ihrem Git-Repo hinzu oder konfigurieren Sie Ihren SSH-Agenten so, dass er die Schlüssel lädt, wenn Sie die Schlüssel immer noch bei sich haben und nicht bei jemand anderem;)

  2. Eine weitere schnelle Lösung besteht darin, in Ihr .git-Verzeichnis zu gehen und den [remote "Origin"] url der config-Datei von git in http zu bearbeiten, so dass keine ssh-Schlüssel für Push erforderlich sind und der Benutzername und das Kennwort abgefragt werden.

    [remote "Origin"]
    url = [email protected]*****.com:****/****.git
    fetch = +refs/heads/*:refs/remotes/Origin/*
    

Ändern 

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

TL; DR: Lassen Sie [email protected] in Ihren Remote-URLs unter Windows nicht aus.

Unter Linux und Windows mit der Standardeinstellung ssh können Sie den Benutzernamen in fernen URLs weglassen, wie folgt:

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

Weil ssh standardmäßig nur den Benutzernamen verwendet, mit dem Sie gerade angemeldet sind. Wenn Sie unter Windows git für die Verwendung von plink.exe eingerichtet haben, sodass Sie den in pageant geladenen Schlüssel verwenden können, funktioniert dies nicht, da plink dies nicht hat Das gleiche Verhalten bei automatischem Benutzernamen führt zu diesen kryptischen Fehlermeldungen, da der Benutzername abgefragt wird:

$ plink server-name
login as: _

Gegen:

$ plink [email protected]
...logs you in...

Wenn Sie bereits ein Repository geklont haben, können Sie die Fernbedienungen in Ihrem .git/config reparieren, indem Sie den [email protected] zur fernen URL hinzufügen.

0
jlh

sie können jederzeit einen http-Link zu Ihrem Git-Projekt haben. Sie können das anstelle von ssh link verwenden. Dies ist nur eine Option, die Sie haben

0
Mohanakrrishna

Das Ändern der ssh-Datei von builtin in nativ unter Einstellungen/Versionskontrolle/git hat den Trick für mich gemacht.

0
Hakaishin

Es könnte sich um einen Sicherheitszugriff auf Ihrem Computer handeln. Führen Sie Pageant aus (was ein PuTTY-Agent ist)?

0
Kevin Davis

Wir sind auch darauf gestoßen.

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

Ich kenne die Details nicht, was schief gelaufen ist, aber in unserem Fall war es die Ursache, dass die Festplatte des Servers voll war.

0
anr78

Wenn Sie PuTTY verwenden. Stellen Sie dann sicher, dass Pageant ausgeführt wird und Ihr privater Schlüssel in Pageant geladen ist.

Ansonsten, wenn Sie in cmd.exe vorgehen:

git clone ssh://[email protected]:/path/to/git/repo.git

sie erhalten diese Meldung "fatal: Protokollfehler: Zeichen für schlechte Leitungslänge:"

0
display_name

Nun, ich hatte das gleiche Problem (Windows 7). Versuchen Sie Repo per Passwort zu bekommen ..__ Ich benutze Git Bash + Plink (Umgebungsvariable GIT_SSH) + Pageant . Das Löschen von GIT_SSH (temporär) hilft mir. Ich weiß nicht, warum ich mich nicht gleichzeitig über RSA anmelden und gleichzeitig mit RSA anmelden kann ...

0