Git Remote: Error: fatal: error de protocolo: carácter de longitud de línea incorrecta: Unab

Configuré un servidor git y ahora quiero enviar inicialmente mi repositorio desde el cliente. Usé git push origin mastery recibí este mensaje de error:

fatal: protocol error: bad line length character: Unab

No se lo que está mal. No sé qué es "Unab". Intenté cambiar el tamaño del shell pero sigue siendo "Unab". No puedo encontrar una solución para este mensaje de error.

Configuré el servidor con "claves_autorizadas" y SSH. (Puedo conectarme a él mediante SSH).

¿Parece ser un problema de git?

Por cierto: el servidor está configurado en una máquina virtual de Windows 7

Este mensaje de error es un poco obtuso, pero lo que en realidad está tratando de decirte es que el servidor remoto no respondió con una respuesta de git adecuada. Al final, hubo un problema en el servidor que ejecuta el git-receive-packproceso.

En el protocolo Git, los primeros cuatro bytes deben ser la longitud de la línea. En cambio, eran los personajes Unab... lo que probablemente sea el comienzo de un mensaje de error de algún tipo. (es decir, probablemente sea " Unable to..." hacer algo).

¿Qué pasa cuando corres ssh <host> git-receive-pack <path-to-git-repository>? Debería ver el mensaje de error de que su cliente git está vomitando y es posible que pueda corregirlo.

Tuve un problema similar, pero el mensaje de error exacto fue:

fatal: error de protocolo: carácter de longitud de línea incorrecta: Usin

Esto está en Windows, con GIT_SSHla ruta plink.exede PuTTY.

Posibles problemas y soluciones:

• Asegúrese de que la ruta a plink.exesea ​​correcta. La ruta de estilo Unix también funciona bien, por ejemplo/c/work/tools/PuTTY/plink.exe
• Asegúrese de que el agente clave de PuTTY ( pageant.exe) se esté ejecutando
• Asegúrese de que el agente de claves contenga una clave válida para acceder al servidor

Para usuarios de GitExtension:

Enfrenté el mismo problema después de actualizar git a 2.19.0

Solución:

Herramientas> Configuración> Extensiones de Git> SSH

Seleccione [ OpenSSH ] en lugar de [ PuTTY ]

Tuve el mismo tipo de problema después de instalar GIT en Windows. Al principio funcionó; luego, un día después (después de reiniciar la PC), ya no lo hizo, y obtuve esto:

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

El problema era que después del reinicio, el Putty "pageant.exe" iniciado automáticamente ya no tenía la clave privada activa. Cuando agrega una clave en el concurso, no es una configuración persistente por defecto. Solo tuve que agregar la clave nuevamente, y funcionó bien. Entonces, para ese caso, es necesario hacer que pagenant cargue la clave automáticamente, como se explica aquí:

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

Tal vez tenga una declaración en el .bashrc del servidor que produce una salida. Yo, por ejemplo, tuve esto:

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

En este caso, la salida del uso de rvm se interpretará (incorrectamente) como proveniente de git. Así que reemplázalo por:

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

Después de cargar la clave privada SSH en Git Extensions, este problema se resuelve.

Puede redirigir cualquier salida de .bashrca stderr:

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

git ignorará estos símbolos

Tuve un problema similar en Windows usando Git Bash. Seguí recibiendo este error al intentar hacer un clon de git. El repositorio estaba en una caja de Linux con GitLab instalado.

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

Me aseguré de que se generara la clave ssh. La clave pública se agregó en GitLab. El agente ssh se estaba ejecutando y se agregó la clave generada ( enlace de github ).

Me quedé sin opciones y finalmente intenté cerrar Git Bash y abrirlo nuevamente haciendo clic derecho en 'Ejecutar como administrador'. Trabajó después de eso.

Esto podría ayudar a alguien. Cuando intentaba clonar un proyecto desde una instancia EC2, recibía el siguiente error:

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

La resolución para mí incluye los siguientes pasos:

1. Asegúrese de que la clave SSH (pública) se agregue / actualice en la instancia EC2.
2. Asegúrese de que el agente de autenticación (en mi caso su Pageant = Putty Authentication Agent) se esté ejecutando y la clave privada correspondiente esté cargada.

3. Use el ID de la clave SSH de EC2 para la clave pública para git clone. Ejemplo:

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

Para mí fue porque recientemente agregué

RequestTTY force

en .ssh / config

comentar esto permitió que funcionara

Verifique sus archivos de inicio en la cuenta utilizada para conectarse a la máquina remota para ver si hay declaraciones de "eco". Para el shell Bash, estos serían su .bashrc y .bash_profile, etc. Edward Thomson tiene razón en su respuesta, pero un problema específico que he experimentado es cuando hay una impresión de la placa de la caldera al iniciar sesión en un servidor a través de ssh. Git obtendrá los primeros cuatro bytes de esa placa de caldera y generará este error. Ahora, en este caso específico, voy a adivinar que "Unab" es en realidad el trabajo "No se puede ...", lo que probablemente indica que hay algo más mal en el host Git.

En mi caso después de buscar a que fue escrito: fatal: protocol error: bad line length character: Pass. También después de empuje que tengo: fatal: protocol error: bad line length character: git@ Done.

Después de reiniciar Windows, tuve que iniciar "PuTTY agent" (pageant.exe) nuevamente y agregar una clave privada que desapareció de una lista de claves.

Para su información, recibí este mismo mensaje de error después de actualizar un contenedor CentOS6 a CentOS7: algunas operaciones de git comenzaron a fallar al construir el contenedor, por ejemplo

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

Ejecutar ssh me dio un error en el que podía buscar:

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

Eso me llevó a https://github.com/wolfcw/libfaketime/issues/63 donde me di cuenta de que había olvidado que tenía un LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1archivo Dockerfile principal. Comentar eso solucionó el error.

En mi caso, el problema fue Putty de 32 bits y pageant.exe; no se puede comunicar con TortoisePlink.exe de 64 bits. Reemplazar Putty de 32 bits por una versión de 64 bits resolvió el problema.

Tuve el mismo error "fatal: protocol error: bad line length character: shmi" donde shmies el nombre de usuario en mi caso. Cambié SSH de PuTTY a OpenSSH en "Git Extensions->Settings->SSH". Eso ayudo.

Tuve el mismo problema que Christer Fernstrom. En mi caso, fue un mensaje que había puesto en mi .bashrc que me recuerda hacer una copia de seguridad cuando no he hecho una en un par de días.

Lo siguiente puede ayudar a alguien: Al intentar clonar un proyecto que tengo en mi instancia de AWS EC2, recibí el siguiente error:

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

Esto fue causado por intentar ssh como root en lugar de EC2-USER. si realmente ssh sin hacer un clon de git ... verá el mensaje de error en algo como "Por favor, inicie sesión con ec2-user". Una vez que hice un clon de git como usuario de ec2, fue bueno.

También encuentro ese error de vez en cuando, pero cuando lo hace, significa que mi sucursal no está actualizada, así que tengo que hacerlo git pull origin <current_branch>

Git no solicita la contraseña y falla con un mensaje críptico similar "fatal: error de protocolo: carácter de longitud de línea incorrecta: usuario" si no tiene su configuración de autenticación de clave privada también.

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server indica cómo especificar la clave pública en el servidor. Básicamente, agregue la clave pública a ~ / .ssh / allowed_keys o ~ / .ssh / allowed_keys2

Tuve que luchar un poco sobre cómo proporcionar una clave privada al Git Bash en la máquina con Windows. La respuesta de Dan McClain en /server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 describe eso. Una adición a su respuesta, en mi caso, se esperaba que el archivo de clave privada se llamara id_rsa.pub

Para mí, agregar los mismos detalles del host en Putty con la clave privada (convertir con puttygen) funcionó. Cualquier comando de git bash después de eso no tuvo problemas.

Si usa Putty. Luego, asegúrese de que Pageant se esté ejecutando y su clave privada esté cargada en Pageant (haga clic con el botón derecho del mouse en el icono de Pageant en la barra de tareas y haga clic en "Ver claves" en el menú emergente).

De lo contrario, cuando lo haga en cmd.exe:

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

aparece este mensaje "fatal: error de protocolo: carácter de longitud de línea incorrecta:"

TL; DR: No omita en sus URL remotas cuando estéusername@ en Windows.

En Linux y en Windows con el ssh predeterminado, puede omitir el nombre de usuario de las URL remotas, así:

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

Porque el comportamiento predeterminado de ssh es usar cualquier nombre de usuario con el que haya iniciado sesión actualmente. Si está en Windows y ha configurado git para usar de plink.exemodo que pueda usar la clave cargada en su pageant, entonces esto no funcionará, porque plinkno tiene este mismo comportamiento de nombre de usuario automático, lo que resulta en esos mensajes de error crípticos, porque lo hará solicitar el nombre de usuario:

$ plink server-name
login as: _

Versus:

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

Si ya clonó un repositorio de alguna manera, puede arreglar los controles remotos en su .git/configagregando el username@a la URL remota.

Compruebe si el acceso a Shell está permitido en el servidor.

El error se transformó en: fatal: error de protocolo: carácter de longitud de línea incorrecta: fata

después de agregar la ubicación de git-upload-pack a la ruta del sistema.

El problema parece ser un apóstrofe agregado alrededor del nombre del repositorio: buscando con una herramienta como Process Monitor (de sys internos), que fueron agregadas por el cliente git. Parece ser un problema de Windows específico de git.

Probé la misma línea de comando en el indicador del servidor: el error completo fue "fatal: no es un repositorio dado (o cualquiera de los directorios principales): .git"

En conclusión, a mí me parece un error de software. Tenga en cuenta que no soy un experto en git, es la primera vez que uso git, vengo de subversión y forzosamente.

También nos encontramos con esto.

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

No conozco los detalles sobre lo que salió mal, pero en nuestro caso lo que provocó fue que el disco en el servidor estaba lleno.

Podría ser un acceso de seguridad en su máquina, ¿está ejecutando Pageant (que es un agente de masilla)?

siempre puede tener un enlace http a su proyecto git. Puede usar eso en lugar del enlace ssh. Esta es solo una opción que tienes

Bueno, tuve el mismo problema (Windows 7). Intente obtener un repositorio con contraseña. Yo uso Git Bash + Plink (variable de entorno GIT_SSH) + Pageant. Eliminar GIT_SSH (temporal) me ayuda. No sé por qué no puedo usar el inicio de sesión por contraseña y el inicio de sesión con RSA al mismo tiempo ...

Respuesta tardía aquí, pero espero que ayude a alguien. Si es un error de protocolo, tiene que hacer algo con su git local que no puede comunicarse con el git remoto. Esto puede suceder si clonó el repositorio a través de ssh y, en algún momento, perdió las claves del repositorio o si su agente ssh ya no puede encontrar esas claves.

Solución

1. Genere una nueva clave y agréguela a su repositorio de git o configure su agente ssh para cargar las claves si todavía tiene las claves con usted y no con otra persona;)

2. Otra solución rápida es ir a su .gitdirectorio y editar el configarchivo [remote "origin"] urlde gita httppara que las claves ssh no sean necesarias para presionar y volverá a solicitar su nombre de usuario y contraseña.

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

Cambiar a

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

Cambiar el exectuable ssh de incorporado a nativ en settings / version control / git funcionó para mí.