Git Remote: Fehler: schwerwiegend: Protokollfehler: fehlerhafte Zeilenlänge Zeichen: Unab

Ich habe einen Git-Server eingerichtet und möchte jetzt zunächst mein Repo vom Client pushen. Ich habe git push origin masterdiese Fehlermeldung verwendet und erhalte sie:

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 sie ist immer noch "Unab". Ich kann keine Lösung für diese Fehlermeldung finden.

Ich richte den Server mit "authorized_keys" und SSH ein. (Ich kann mit SSH eine Verbindung herstellen.)

Es scheint ein Git-Problem zu sein?

Übrigens: Der Server ist in einer Windows 7-VM eingerichtet

Diese Fehlermeldung ist etwas stumpf, aber sie versucht Ihnen tatsächlich zu sagen, dass der Remote-Server nicht mit einer richtigen Git-Antwort geantwortet hat. Letztendlich gab es ein Problem auf dem Server, auf dem der git-receive-packProzess ausgeführt wurde.

Im Git-Protokoll sollten die ersten vier Bytes die Zeilenlänge sein. Stattdessen waren sie die Charaktere Unab... was wahrscheinlich der Anfang einer Fehlermeldung ist. (dh es ist wahrscheinlich " Unable to..." etwas zu tun).

Was passiert beim Laufen ssh <host> git-receive-pack <path-to-git-repository>? Sie sollten die Fehlermeldung sehen, die Ihr Git-Client aktiviert, und Sie können sie möglicherweise korrigieren.

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

fatal: Protokollfehler: fehlerhafte Zeilenlänge Zeichen: Usin

Dies ist in Windows mit GIT_SSHdem Pfad plink.exevon PuTTY eingestellt.

Mögliche Probleme und Lösungen:

• Stellen Sie sicher, dass der Pfad zu plink.exekorrekt ist. Der Pfad im Unix-Stil funktioniert beispielsweise auch einwandfrei/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

Für GitExtension-Benutzer:

Ich hatte das gleiche Problem, nachdem ich git auf 2.19.0 aktualisiert hatte

Lösung:

Extras> Einstellungen> Git-Erweiterungen> SSH

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

Ich hatte das gleiche Problem nach der Installation von GIT unter Windows. Zuerst hat es funktioniert; dann, einen Tag später (nach einem PC-Neustart), tat es nicht mehr und ich bekam Folgendes:

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

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 erneut hinzufügen, und es funktionierte gut. In diesem Fall muss der Pagenant den Schlüssel automatisch laden, wie hier beschrieben:

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

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

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

In diesem Fall wird die Ausgabe der rvm-Verwendung (fälschlicherweise) als von git stammend interpretiert. Ersetzen Sie es also durch:

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

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

Sie können jede Ausgabe von umleiten .bashrczu stderr:

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

git ignoriert diese Symbole

Ich hatte ein ähnliches Problem unter Windows mit Git Bash. Ich habe diesen Fehler immer wieder erhalten, wenn ich versucht habe, einen Git-Klon zu erstellen. Das Repository befand sich auf einer Linux-Box mit installiertem GitLab.

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

Ich habe dafür gesorgt, 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 wieder zu öffnen, indem ich mit der rechten Maustaste auf "Als Administrator ausführen" klickte. Arbeitete danach.

Dies könnte jemandem helfen. Beim Versuch, ein Projekt von einer EC2-Instanz zu klonen, wurde der folgende Fehler angezeigt:

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

Die Auflösung umfasst 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 ist.

3. Verwenden Sie die EC2-SSH-Schlüssel-ID für den öffentlichen Schlüssel für den Git-Klon. Beispiel:

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

Für mich war es, weil ich kürzlich hinzugefügt habe

RequestTTY force

in .ssh / config

Durch das Auskommentieren konnte es funktionieren

Überprüfen Sie Ihre Startdateien auf dem Konto, mit dem eine Verbindung zum Remotecomputer hergestellt wurde, auf "Echo" -Anweisungen. Für die Bash-Shell wären dies Ihr .bashrc- und .bash_profile usw. Edward Thomson ist in seiner Antwort korrekt, aber ein spezielles Problem, das ich erlebt habe, ist, wenn beim Anmelden bei einem Server über ssh ein Boiler-Plate-Ausdruck auftritt. Git erhält die ersten vier Bytes dieser Kesselplatte und löst diesen Fehler aus. In diesem speziellen Fall werde ich vermuten, dass "Unab" tatsächlich die Arbeit "Unable ..." ist, was wahrscheinlich darauf hinweist, dass auf dem Git-Host etwas anderes nicht stimmt.

In meinem Fall wurde nach dem Abrufen geschrieben : fatal: protocol error: bad line length character: Pass. Auch nach dem Push bekam ich : fatal: protocol error: bad line length character: git@ 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 war.

Zu Ihrer Information: Nach dem Upgrade eines CentOS6-Containers auf CentOS7 wurde dieselbe Fehlermeldung angezeigt. Einige Git-Vorgänge schlugen beim Erstellen des Containers fehl, 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 git@bitbucket.org
Invalid clock_id for clock_gettime: 7

Das führte mich zu https://github.com/wolfcw/libfaketime/issues/63, wo mir klar wurde, dass ich vergessen hatte, dass ich LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1eine Docker-Datei in einem Elternteil hatte. Durch Auskommentieren wurde der Fehler behoben.

In meinem Fall war das Problem 32-Bit Putty und pageant.exe - es kann nicht mit 64-Bit TortoisePlink.exe kommunizieren. Das Ersetzen von 32-Bit-Putty durch eine 64-Bit-Version löste das Problem.

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

Ich hatte das gleiche Problem wie Christer Fernstrom. In meinem Fall war es eine Nachricht, die ich in meine .bashrc-Datei eingefügt hatte und die mich daran erinnert, ein Backup zu erstellen, wenn ich seit einigen Tagen kein Backup mehr erstellt habe.

Folgendes kann jemandem helfen: Beim Versuch, ein Projekt auf meiner AWS EC2-Instanz zu klonen, 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 tatsächlich ssh ohne einen Git-Klon ausführen ... sehen Sie die Fehlermeldung in der Art von "Bitte mit ec2-Benutzer anmelden". Nachdem ich einen Git-Klon als ec2-Benutzer erstellt habe, war es gut.

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 es tun git pull origin <current_branch>

Git fordert nicht zur Eingabe eines Kennworts auf und schlägt mit einer ähnlichen kryptischen Meldung "Schwerwiegend: Protokollfehler: Zeichen für ungültige Zeilenlänge: Benutzer" fehl, wenn Sie nicht auch über die Authentifizierung Ihres privaten Schlüssels 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 / autorisierte_Tasten oder ~ / .ssh / autorisierte_Tasten2 hinzu

Ich musste mich ein wenig darum bemühen, wie ich dem Git Bash auf dem Windows-Computer einen privaten Schlüssel zur Verfügung stellen kann. Dan McClains Antwort in /server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 beschreibt dies. Als Ergänzung zu seiner Antwort wurde in meinem Fall erwartet, dass die private Schlüsseldatei den Namen id_rsa.pub trägt

Für mich hat das Hinzufügen der gleichen Host-Details zu Putty mit dem privaten Schlüssel (konvertieren mit puttygen) funktioniert. Alle Git-Bash-Befehle danach hatten keine Probleme.

Wenn Sie Putty verwenden. Stellen Sie dann sicher, dass Pageant ausgeführt wird und Ihr privater Schlüssel in Pageant geladen ist (klicken Sie mit der rechten Maustaste auf das Pageant-Symbol in der Taskleiste und klicken Sie im angezeigten Menü auf "Schlüssel anzeigen").

Andernfalls, wenn Sie in cmd.exe tun:

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

Sie erhalten die Meldung "Schwerwiegend: Protokollfehler: Zeichen für falsche Zeilenlänge:"

TL; DR: Do nicht weglassen username@in der Remote - URLs unter Windows.

Unter Linux und Windows mit dem Standard-SSH können Sie den Benutzernamen in Remote-URLs wie folgt weglassen:

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

Da ssh standardmäßig nur den Benutzernamen verwendet, mit dem Sie gerade angemeldet sind. Wenn Sie unter Windows arbeiten und git plink.exeso eingerichtet haben, dass Sie den in Ihrem Computer geladenen Schlüssel verwenden können pageant, funktioniert dies nicht, da plinkes nicht dasselbe automatische Verhalten des Benutzernamens gibt, was zu diesen kryptischen Fehlermeldungen führt Eingabeaufforderung für den Benutzernamen:

$ plink server-name
login as: _

Gegen:

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

Wenn Sie bereits ein Repository geklont haben, können Sie die Fernbedienungen in Ihrem Repository reparieren, .git/configindem Sie das username@zur Remote-URL hinzufügen .

Überprüfen Sie, ob der Shell-Zugriff auf dem Server zulässig ist.

Der Fehler wurde umgewandelt in: fatal: Protokollfehler: fehlerhafte Zeilenlänge Zeichen: fata

nach dem Hinzufügen des Speicherorts von git-upload-pack zum Systempfad.

Das Problem scheint ein Apostroph zu sein, der um den Repository-Namen herum hinzugefügt wurde: 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 versucht: Der vollständige Fehler war "schwerwiegend: kein bestimmtes Repository (oder eines der übergeordneten Verzeichnisse): .git".

Zusammenfassend scheint es mir ein Software-Fehler zu sein. Seien Sie darauf hingewiesen, dass ich kein Git-Experte bin. Es ist das erste Mal, dass ich Git benutze. Ich komme aus Subversion und Perforce.

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 weiß nicht genau, was schief gelaufen ist, aber in unserem Fall hat es ausgelöst, dass die Festplatte auf dem Server voll war.

Es könnte sich um einen Sicherheitszugriff auf Ihrem Computer handeln. Führen Sie Pageant (einen Kittagenten) aus?

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

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 nicht gleichzeitig Login by Pass und Login mit RSA verwenden kann ...

Späte Antwort hier, aber ich hoffe, es wird jemandem helfen. Wenn es sich um einen Protokollfehler handelt, muss er etwas mit Ihrem lokalen Git tun, das nicht mit dem Remote-Git kommunizieren kann. Dies kann passieren, wenn Sie das Repo über ssh geklont haben und einige Zeit 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. Generiere einen neuen Schlüssel und füge ihn deinem Git-Repo hinzu oder konfiguriere deinen SSH-Agenten so, dass er die Schlüssel lädt, wenn du die Schlüssel noch bei dir hast und nicht bei jemand anderem;)

2. Eine weitere schnelle Lösung besteht darin, in Ihr .gitVerzeichnis zu wechseln und die configDateien [remote "origin"] urlvon gitbis zu bearbeiten , httpsodass zum Drücken keine SSH-Schlüssel erforderlich sind und Sie wieder nach Ihrem Benutzernamen und Passwort gefragt werden.

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

Ändern

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

Das Ändern des SSH-Exectuable von Builtin auf Nativ unter settings / version control / git hat mir geholfen.