generate - git ssh key windows
Git Remote: Error: fatal: error de protocolo: carácter de longitud de línea incorrecta: Unab (26)
Última respuesta 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 clonaste el repositorio a través de ssh y algún tiempo después, perdiste las claves del repositorio o tu agente ssh ya no puede encontrar esas claves.
Solución
Genera una nueva clave y agrégala a tu git repo o configura tu agente ssh para cargar las claves si aún tienes las llaves contigo y no con otra persona;)
Otra solución rápida es ir a su directorio
.gity editar la[remote "origin"] urldel[remote "origin"] urldel archivo deconfigdesdegitahttppara que las claves ssh no sean necesarias para presionar y volverá a preguntar 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/*
Configuré un servidor de git y ahora quiero enviar inicialmente mi informe del cliente. Utilicé el git push origin master y recibí este mensaje de error:
fatal: protocol error: bad line length character: Unab
No se lo que está mal. No sé qué es "Unab". Traté de cambiar el tamaño del caparazón, pero sigue siendo "Unab". No puedo encontrar una solución para este mensaje de error.
Configuro el servidor con "authorized_keys" y SSH. (Puedo conectarme a él, usando SSH).
Parece ser un problema idiota?
Por cierto: el servidor está configurado en una VM con Windows 7
Bueno, tuve este mismo problema (Windows 7). Intenta obtener un repo por contraseña. Uso Git Bash + Plink (variable de entorno GIT_SSH) + Avance. Eliminar GIT_SSH (temporal) me ayuda. No sé por qué no puedo usar el inicio de sesión por pase e iniciar sesión con RSA al mismo tiempo ...
Compruebe si se permite el acceso de Shell en el servidor.
Después de cargar la clave privada SSH en extensiones de Git, este problema se resuelve.
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óstrofo agregado alrededor del nombre del repositorio: mirando con una herramienta como Process Monitor (desde sys internals), que fue agregada por el cliente git. Parece ser un problema de Windows específico de git.
Probé la misma línea de comando en el prompt del servidor: el error completo fue "fatal: no un repositorio dado (o ninguno de los directorios principales): .git"
En conclusión, para mí parece un error de software. Tenga en cuenta que no soy un experto en git, es la primera vez que uso git, vengo de la subversión y forzosamente.
En mi caso después de buscar escribió: "fatal: error de protocolo: carácter de longitud de línea incorrecta: Pase".
Después de reiniciar Windows, tuve que volver a iniciar el agente PuTTY (pageant.exe) y agregar un ket privado que desapareció de una lista de claves.
En mi caso, el problema era Putty de 32 bits y pageant.exe: no se puede comunicar con TortoisePlink.exe de 64 bits. Reemplazar la masilla de 32 bits con una versión de 64 bits resolvió el problema.
Este mensaje de error es un poco obtuso, pero lo que en realidad está tratando de decirle es que el servidor remoto no respondió con una respuesta git adecuada. Finalmente, hubo un problema en el servidor que ejecuta el proceso de git-receive-pack .
En el protocolo de Git, los primeros cuatro bytes deben ser la longitud de línea. En cambio, fueron los personajes Unab ... que probablemente sea el comienzo de un mensaje de error de algún tipo. (es decir, es probable que " Unable to... " hacer algo).
¿Qué ocurre cuando ejecuta ssh <host> git-receive-pack <path-to-git-repository> ? Debería ver el mensaje de error de que su cliente de git está vomitando y puede corregirlo.
Esto podría ayudar a alguien. Cuando intentaba clonar un proyecto de una instancia de 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:
- Asegúrese de que la clave SSH (pública) se haya agregado / actualizado en la instancia de EC2.
- Asegúrese de que el agente de autenticación (en mi caso, el agente de autentificación Pageant = Putty) se esté ejecutando y que se haya cargado la clave privada correspondiente.
Use la ID de la clave EC2 SSH para la clave pública de git clone. Ejemplo:
git clone ssh: // {clave SSH ID}@someaccount.amazonaws.com/v1/repos/repo1
FYI Recibí este mismo mensaje de error después de actualizar un contenedor de 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 podría buscar:
# ssh [email protected]
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.1 en un Dockerfile padre. Al comentar eso solucionó el error.
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 también la configuración de autenticación de clave privada .
https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server le dice cómo especificar la clave pública en el servidor. Básicamente agregue la clave pública a ~ / .ssh / authorized_keys o ~ / .ssh / authorized_keys2
Tuve que luchar un poco sobre cómo proporcionar la clave privada para el Git Bash en la máquina de Windows. La respuesta de Dan McClain en https://serverfault.com/questions/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 la clave privada se llamara id_rsa.pub
Lo siguiente puede ayudar a alguien: cuando intenté clonar un proyecto que tenía en mi instancia de AWS EC2, recibí el siguiente error:
Cloning into ''AWSbareRepo''...
fatal: protocol error: bad line length character: Plea
Esto fue causado al tratar de ssh como root en lugar de EC2-USER. si realmente ssh sin hacer un clon git ... verá el mensaje de error en algo como "Inicie sesión con el usuario ec2". Una vez que hice un clon git como un usuario ec2 fue bueno.
Nos encontramos con esto también.
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 sé los detalles idiotas sobre lo que salió mal, pero en nuestro caso lo que lo desencadenó fue que el disco en el servidor estaba lleno.
Para mí fue porque recientemente agregué
RequestTTY force
en .ssh / config
comentar esto le permitió funcionar
Para mí, agregar los mismos detalles de host en Putty con la clave privada (convertir con puttygen) funcionó. Cualquier comando de git bash después de eso no tuvo problemas.
Podría ser un acceso de seguridad en su máquina, ¿está ejecutando el concurso (que es un agente de masilla)?
Puede redirigir cualquier salida de .bashrc a stderr :
# inside .bashrc
echo ''some error/warning/remind message'' 1>&2
git ignorará estos símbolos
Tal vez tenga una declaración en .bashrc del servidor que produzca resultados. Yo, por ejemplo, tenía esto:
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
rvm use ruby-1.9.3-p194@rails32
En este caso, el resultado del uso de rvm se interpretará (erróneamente) como procedente de git. Así que reemplázalo por:
rvm use ruby-1.9.3-p194@rails32 > /dev/null
También encuentro ese error de vez en cuando, pero cuando lo hace, significa que mi rama no está actualizada, así que tengo que hacer git pull origin <current_branch>
Tuve el mismo error "fatal: protocol error: bad line length character: shmi" Donde el shmi es 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, era un mensaje que había puesto en mi .bashrc que me recuerda hacer una copia de seguridad cuando no he hecho uno en un par de días.
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 el PC), ya no funcionaba, 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" que se iniciaba automáticamente ya no tenía activada la clave privada. 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 la carga cargue la clave automáticamente, como se discute aquí:
Tuve un problema similar en Windows usando Git Bash. Seguí recibiendo este error al intentar hacer un clon 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 ssh-agent se estaba ejecutando y se agregó la clave generada ( enlace github ).
Me quedé sin opciones y finalmente traté de cerrar Git Bash y abrirlo de nuevo haciendo clic derecho en ''Ejecutar como administrador''. Trabajó después de eso.
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_SSH establecido en la ruta de plink.exe de PuTTY.
Posibles problemas y soluciones:
- Asegúrese de que la ruta de acceso a
plink.exesea correcta. La ruta de estilo de 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 clave contenga una clave válida para acceder al servidor
Verifique sus archivos de inicio en la cuenta utilizada para conectarse a la máquina remota para las declaraciones de "eco". Para el shell Bash estos serían sus archivos .bashrc y .bash_profile, etc. Edward Thomson tiene razón en su respuesta, pero un problema específico que he experimentado es cuando hay alguna impresión de placa de caldera al iniciar sesión en un servidor a través de ssh. Git obtendrá los primeros cuatro bytes de esa placa de la caldera y generará este error. Ahora, en este caso específico, voy a adivinar que "Unab" es en realidad el trabajo "Imposible ...", lo que probablemente indica que hay algo más erróneo en el host de Git.
siempre puedes tener un enlace http a tu proyecto git. Puede usarlo en lugar del enlace ssh. Esta es solo una opción que tienes