Git Remote: Errore: irreversibile: errore di protocollo: carattere di lunghezza della riga non valida: Unab

Ho configurato un server git e ora desidero eseguire il push inizialmente del mio repository dal client. Ho usato git push origin mastere ricevo questo messaggio di errore:

fatal: protocol error: bad line length character: Unab

Non so cosa c'è che non va. Non so cosa sia "Unab". Ho provato a ridimensionare la shell ma è ancora "Unab". Non riesco a trovare una soluzione per questo messaggio di errore.

Ho configurato il server con "authorized_keys" e SSH. (Posso collegarmi ad esso, usando SSH.)

Sembra essere un problema git?

BTW: il server è configurato in una VM Windows 7

Questo messaggio di errore è un po 'ottuso, ma quello che sta effettivamente cercando di dirti è che il server remoto non ha risposto con una risposta git adeguata. Infine, si è verificato un problema sul server che esegue il git-receive-packprocesso.

Nel protocollo Git, i primi quattro byte dovrebbero essere la lunghezza della riga. Invece, erano i personaggi Unab... che è probabilmente l'inizio di un messaggio di errore di qualche tipo. (cioè, probabilmente " Unable to..." fa qualcosa).

Cosa succede quando corri ssh <host> git-receive-pack <path-to-git-repository>? Dovresti vedere il messaggio di errore che il tuo client git sta vomitando e potresti essere in grado di correggerlo.

Ho avuto un problema simile, ma il messaggio di errore esatto era:

fatale: errore di protocollo: carattere di lunghezza della riga non valido: Usin

Questo è in Windows, con GIT_SSHimpostato il percorso plink.exedi PuTTY.

Possibili problemi e soluzioni:

• Assicurati che il percorso plink.exesia corretto. Ad esempio, anche il percorso in stile Unix funziona bene/c/work/tools/PuTTY/plink.exe
• Assicurati che l'agente chiave di PuTTY ( pageant.exe) sia in esecuzione
• Assicurati che l'agente chiave contenga una chiave valida per accedere al server

Per gli utenti di GitExtension:

Ho riscontrato lo stesso problema dopo aver aggiornato git a 2.19.0

Soluzione:

Strumenti> Impostazioni> Estensioni Git> SSH

Seleziona [ OpenSSH ] invece di [ PuTTY ]

Ho avuto lo stesso tipo di problema dopo aver installato GIT su Windows. All'inizio ha funzionato; poi, un giorno dopo (dopo un riavvio del PC), non è più successo e ho ottenuto questo:

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

Il problema era che dopo il riavvio, Putty "pageant.exe" avviato automaticamente non aveva più la chiave privata attiva. Quando aggiungi una chiave in pageant, non è un'impostazione persistente per impostazione predefinita. Ho solo dovuto aggiungere di nuovo la chiave e ha funzionato bene. Quindi, per quel caso, è necessario fare in modo che pagenant carichi automaticamente la chiave, come discusso qui:

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

Forse hai un'istruzione nel .bashrc del server che produce l'output. Io, ad esempio, avevo questo:

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

In questo caso l'output dell'uso di rvm verrà (erroneamente) interpretato come proveniente da git. Quindi sostituiscilo con:

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

Dopo aver caricato la chiave privata SSH in Git Extensions, questo problema viene risolto.

Puoi reindirizzare qualsiasi output da .bashrca stderr:

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

git ignorerà questi simboli

Ho avuto un problema simile su Windows utilizzando Git Bash. Continuavo a ricevere questo errore quando provavo a fare un clone di git. Il repository era su una macchina Linux con GitLab installato.

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

Mi sono assicurato che la chiave ssh fosse generata. La chiave pubblica è stata aggiunta su GitLab. L'ssh-agent era in esecuzione e la chiave generata è stata aggiunta ( collegamento github ).

Ho esaurito le opzioni e alla fine ho provato a chiudere Git Bash e riaprirlo facendo clic con il pulsante destro del mouse su "Esegui come amministratore". Ha lavorato dopo.

Questo potrebbe aiutare qualcuno. Quando stavo cercando di clonare un progetto da un'istanza EC2, ricevevo l'errore seguente:

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

La risoluzione per me include i passaggi seguenti:

1. Assicurati che la chiave SSH (pubblica) sia aggiunta / aggiornata nell'istanza EC2.
2. Assicurati che l'agente di autenticazione (nel mio caso il suo Pageant = Putty Authentication Agent) sia in esecuzione e che la chiave privata corrispondente sia caricata.

3. Utilizza l'ID chiave SSH EC2 per la chiave pubblica per git clone. Esempio:

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

Per me è stato perché ho aggiunto di recente

RequestTTY force

in .ssh / config

commentare questo gli ha permesso di funzionare

Controlla i tuoi file di avvio sull'account utilizzato per connettersi alla macchina remota per le istruzioni "echo". Per la shell Bash questi sarebbero i tuoi .bashrc e .bash_profile ecc. Edward Thomson ha ragione nella sua risposta, ma un problema specifico che ho riscontrato è quando c'è una stampa di boiler-plate all'accesso a un server tramite ssh. Git otterrà i primi quattro byte di quel boiler-plate e solleverà questo errore. Ora, in questo caso specifico, immagino che "Unab" sia in realtà il lavoro "Unable ..." che probabilmente indica che c'è qualcos'altro che non va sull'host Git.

Nel mio caso, dopo recuperare è stato scritto: fatal: protocol error: bad line length character: Pass. Anche dopo spinta ho ricevuto: fatal: protocol error: bad line length character: git@ Done.

Dopo il riavvio di Windows ho dovuto riavviare "PuTTY agent" (pageant.exe) e aggiungere una chiave privata che era scomparsa da un elenco di chiavi.

Cordiali saluti, ho ricevuto questo stesso messaggio di errore dopo aver aggiornato un contenitore CentOS6 a CentOS7: alcune operazioni git hanno iniziato a non riuscire durante la creazione del contenitore, ad es.

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

L'esecuzione di ssh mi ha dato un errore su cui ho potuto cercare:

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

Questo mi ha portato a https://github.com/wolfcw/libfaketime/issues/63 dove mi sono reso conto di aver dimenticato di avere un LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1Dockerfile genitore. Commentare questo ha risolto l'errore.

Nel mio caso il problema era Putty a 32 bit e pageant.exe: non può comunicare con TortoisePlink.exe a 64 bit. La sostituzione di Putty a 32 bit con una versione a 64 bit ha risolto il problema.

Ho avuto lo stesso errore "fatal: protocol error: bad line length character: shmi" dove shmiè il nome utente nel mio caso. Ho cambiato SSH da PuTTY a OpenSSH in "Git Extensions->Settings->SSH". Ha aiutato.

Ho avuto lo stesso problema di Christer Fernstrom. Nel mio caso era un messaggio che avevo inserito nel mio .bashrc che mi ricorda di fare un backup quando non ne ho fatto uno da un paio di giorni.

Quanto segue può aiutare qualcuno: Durante il tentativo di clonare un progetto che ho sulla mia istanza AWS EC2, ho ricevuto il seguente errore:

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

Ciò è stato causato dal tentativo di ssh come root invece di EC2-USER. se effettivamente ssh senza fare un clone di git ... vedrai il messaggio di errore in qualcosa del tipo "Effettua il login con ec2-user" Una volta che ho fatto un clone di git come utente ec2, è andato tutto bene.

anche io incontro quell'errore di tanto in tanto, ma quando lo fa, significa che il mio ramo non è aggiornato quindi devo farlo git pull origin <current_branch>

Git non richiede la password e non riesce con un messaggio criptico simile "fatal: protocol error: bad line length character: user" se non si dispone anche della configurazione dell'autenticazione della chiave privata .

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server spiega come specificare la chiave pubblica sul server. Fondamentalmente aggiungi la chiave pubblica a ~ / .ssh / authorized_keys o ~ / .ssh / authorized_keys2

Ho dovuto lottare un po 'su come fornire la chiave privata a Git Bash sulla macchina Windows. La risposta di Dan McClain in /server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 lo descrive. Un'aggiunta alla sua risposta, nel mio caso il file della chiave privata doveva essere chiamato id_rsa.pub

Per me l'aggiunta degli stessi dettagli dell'host in Putty con la chiave privata (conversione con puttygen) ha funzionato. Qualsiasi comando git bash successivo non ha avuto problemi.

Se usi Putty. Quindi assicurati che Pageant sia in esecuzione e che la tua chiave privata sia caricata in Pageant (fai clic con il pulsante destro del mouse sull'icona Pageant sulla barra delle applicazioni e fai clic su "Visualizza chiavi" nel menu che si apre).

Altrimenti quando lo fai in cmd.exe:

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

viene visualizzato il messaggio "fatale: errore di protocollo: carattere di lunghezza della riga non valido:"

TL; DR: Do non omettere username@negli URL remoti quando su Windows.

Su Linux e su Windows con ssh predefinito, puoi omettere il nome utente dagli URL remoti, in questo modo:

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

Perché il comportamento predefinito di ssh è usare solo il nome utente con cui sei attualmente connesso. Se sei su Windows e hai impostato git da usare in plink.exemodo da poter usare la chiave caricata nel tuo pageant, allora questo non funzionerà, perché plinknon ha lo stesso comportamento automatico del nome utente, risultando in quei messaggi di errore criptici, perché lo farà richiedere il nome utente:

$ plink server-name
login as: _

Contro:

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

Se hai già clonato un repository in qualche modo puoi aggiustare i telecomandi nel tuo .git/configaggiungendo username@all'URL remoto.

Verificare se l'accesso Shell è consentito sul server.

L'errore si è trasformato in: fatal: protocol error: bad line length character: fata

dopo aver aggiunto la posizione di git-upload-pack al percorso di sistema.

Il problema sembra essere un apostrofo aggiunto attorno al nome del repository: Guardando con uno strumento come Process Monitor (da sys internals), che sono stati aggiunti dal client git. Sembra essere un problema di Windows specifico di git.

Ho provato la stessa riga di comando nel prompt del server: l'errore completo era "fatale: non un dato repository (o nessuna delle directory principali): .git"

In conclusione, a me sembra un bug del software. Tieni presente che non sono un esperto di git, è la prima volta che uso git, vengo da sovversione e per forza.

Ci siamo imbattuti anche in questo.

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

Non conosco i dettagli gitty su cosa è andato storto, ma nel nostro caso ciò che l'ha attivato è stato che il disco del server era pieno.

Potrebbe essere un accesso di sicurezza sulla tua macchina, stai eseguendo Pageant (che è un agente di stucco)?

puoi sempre avere un link http al tuo progetto git. Puoi usarlo al posto del collegamento ssh. Questa è solo un'opzione che hai

Bene, ho avuto lo stesso problema (Windows 7). Prova a ottenere il repo tramite password. Uso Git Bash + Plink (variabile d'ambiente GIT_SSH) + Pageant. L'eliminazione di GIT_SSH (temporanea) mi aiuta. Non so perché non riesco a utilizzare il login by pass e il login con RSA allo stesso tempo ...

Risposta in ritardo qui, ma spero che possa aiutare qualcuno. Se è un errore di protocollo, ha a che fare con il tuo git locale che non è in grado di comunicare con il git remoto. Questo può accadere se hai clonato il repository tramite ssh e qualche tempo dopo, hai perso le chiavi del repository o il tuo agente ssh non riesce più a trovare quelle chiavi.

Soluzione

1. Genera una nuova chiave e aggiungila al tuo repository git o configura il tuo agente ssh per caricare le chiavi se hai ancora le chiavi con te e non con qualcun altro;)

2. Un'altra soluzione rapida è andare nella .gitdirectory e modificare il configfile [remote "origin"] urlda gita in httpmodo che le chiavi ssh non siano necessarie per il push e tornerà a chiedere il nome utente e la password.

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

Cambia in

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

Cambiare l'eseguibile ssh da builtin a nativ in settings / version control / git ha fatto il trucco per me.