Ich habe einen Git-Server eingerichtet und möchte jetzt zunächst mein Repo vom Client pushen. Ich habe git push origin master
diese 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
git
ssh
authorized-keys
user437899
quelle
quelle
Antworten:
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-pack
Prozess 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.quelle
ssh <host> /bin/true
sollte nichts ausgeben..bashrc
Computer auf dem Computer, auf dem sich das Git-Repository befand, von dem ich abrufen wollte, hatte eine Zeile, die ein Echo auf die Standardausgabe erzeugte. (Das heißt, ich war der Eigentümer des Repositorys auf dem Remotecomputer, also war es mein Eigentümer.bashrc
, der das Problem verursacht hat.) Ich habe den von Benutzer ruslo angegebenen Trick in einer anderen Antwort verwendet, nämlich die Ausgabe dieses Befehls von stdout nach stderr umzuleiten (some_command 1>&2
). Danachgit pull
wieder gearbeitet.0000
und den Cursor unmittelbar danach, als ob eine andere Zeile ausgeschrieben, aber nie abgeschlossen werden soll.Ich hatte ein ähnliches Problem, aber die genaue Fehlermeldung lautete:
Dies ist in Windows mit
GIT_SSH
dem Pfadplink.exe
von PuTTY eingestellt.Mögliche Probleme und Lösungen:
plink.exe
korrekt ist. Der Pfad im Unix-Stil funktioniert beispielsweise auch einwandfrei/c/work/tools/PuTTY/plink.exe
pageant.exe
) ausgeführt wirdquelle
fatal: protocol error: bad line length character: git@
. Was für eine irreführende Fehlermeldung.Ich hatte das gleiche Problem, nachdem ich git auf 2.19.0 aktualisiert hatte
Extras> Einstellungen> Git-Erweiterungen> SSH
Wählen Sie [ OpenSSH ] anstelle von [ PuTTY ]
quelle
fatal: protocol error: bad line length character: git@
. Stellen Sie sicher, dass der SSH-Schlüssel generiert und zu GitLab hinzugefügt wird . Möglicherweise war der Neustart von Git Extensions notwendig.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:
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
quelle
Möglicherweise haben Sie eine Anweisung in der .bashrc des Servers, die eine Ausgabe erzeugt. Ich hatte zum Beispiel folgendes:
In diesem Fall wird die Ausgabe der rvm-Verwendung (fälschlicherweise) als von git stammend interpretiert. Ersetzen Sie es also durch:
quelle
Nach dem Laden des privaten SSH-Schlüssels in Git Extensions wird dieses Problem behoben.
quelle
Sie können jede Ausgabe von umleiten
.bashrc
zustderr
:git ignoriert diese Symbole
quelle
rvm use 2.0.0-p353
in meiner.bashrc
, die verwirrt haben mussgit pull
. Nach dem Anhängen1>&2
und erneuten Versuchengit pull
funktionierte gut.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.
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.
quelle
Dies könnte jemandem helfen. Beim Versuch, ein Projekt von einer EC2-Instanz zu klonen, wurde der folgende Fehler angezeigt:
Die Auflösung umfasst für mich die folgenden Schritte:
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
quelle
plink <server_name> ls
tun, druckt Plink als Erstes auf stdout. Dieserlogin as
Git scheint zu versuchen, ihn als etwas Wichtiges zu interpretieren. Eine schnelle Lösung ist einfachunset GIT_SSH
undunset SVN_SSH
. Weitere Infos hierset GIT_SSH=
undset SVN_SSH=
Für mich war es, weil ich kürzlich hinzugefügt habe
in .ssh / config
Durch das Auskommentieren konnte es funktionieren
quelle
Ü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.
quelle
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.
quelle
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
Das Ausführen von ssh gab mir einen Fehler, nach dem ich suchen konnte:
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.1
eine Docker-Datei in einem Elternteil hatte. Durch Auskommentieren wurde der Fehler behoben.quelle
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.
quelle
Ich hatte den gleichen Fehler
"fatal: protocol error: bad line length character: shmi"
Wo dershmi
Benutzername in meinem Fall ist. Ich habe SSH von PuTTY auf OpenSSH umgestellt"Git Extensions->Settings->SSH"
. Es half.quelle
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.
quelle
Folgendes kann jemandem helfen: Beim Versuch, ein Projekt auf meiner AWS EC2-Instanz zu klonen, wurde der folgende Fehler angezeigt:
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.
quelle
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>
quelle
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
quelle
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.
quelle
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:"
quelle
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:
Da ssh standardmäßig nur den Benutzernamen verwendet, mit dem Sie gerade angemeldet sind. Wenn Sie unter Windows arbeiten und git
plink.exe
so eingerichtet haben, dass Sie den in Ihrem Computer geladenen Schlüssel verwenden könnenpageant
, funktioniert dies nicht, daplink
es nicht dasselbe automatische Verhalten des Benutzernamens gibt, was zu diesen kryptischen Fehlermeldungen führt Eingabeaufforderung für den Benutzernamen:Gegen:
Wenn Sie bereits ein Repository geklont haben, können Sie die Fernbedienungen in Ihrem Repository reparieren,
.git/config
indem Sie dasusername@
zur Remote-URL hinzufügen .quelle
git remote set-url origin myusername@...
hat mir geholfen.Überprüfen Sie, ob der Shell-Zugriff auf dem Server zulässig ist.
quelle
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.
quelle
Wir sind auch darauf gestoßen.
Ich weiß nicht genau, was schief gelaufen ist, aber in unserem Fall hat es ausgelöst, dass die Festplatte auf dem Server voll war.
quelle
Es könnte sich um einen Sicherheitszugriff auf Ihrem Computer handeln. Führen Sie Pageant (einen Kittagenten) aus?
quelle
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
quelle
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 ...
quelle
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
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;)
Eine weitere schnelle Lösung besteht darin, in Ihr
.git
Verzeichnis zu wechseln und dieconfig
Dateien[remote "origin"] url
vongit
bis zu bearbeiten ,http
sodass zum Drücken keine SSH-Schlüssel erforderlich sind und Sie wieder nach Ihrem Benutzernamen und Passwort gefragt werden.Ändern
quelle
Das Ändern des SSH-Exectuable von Builtin auf Nativ unter settings / version control / git hat mir geholfen.
quelle