pide - guardar credenciales git
La gitosis requiere una contraseña a pesar de que se da la clave pública (11)
El mismo problema, y en mi caso fue que tenía incorrectamente authorized_keys en .ssh /. Debo haberlo arruinado en algún momento ...
Me enfrento a algunos problemas al intentar configurar la gitosis en mi Archlinux
http://wiki.archlinux.org/index.php/Setting_Up_Git_ACL_Using_gitosis
Me referí a este artículo wiki e instalé con éxito la gitosis.
$ sudo pacman -U gitosis-git-20090525-1-i686.pkg.tar.gz
$ sudo -H -u gitosis gitosis-init </tmp/id_rsa.pub
Y modifiqué /srv/gitosis/.ssh/authorized_keys para incluir el id_rsa.pub de mi usuario local.
Pero cuando ejecuto git clone como usuario local,
$ git clone gitosis @ host: gitosis-admin.git
Dice
Se inicializó el repositorio de Git vacío en /home/wyx/gitosis-admin/.git/
Contraseña de [email protected]: *****
fatal: ''gitosis-admin.git'' no parece ser un repositorio git
fatal: el extremo remoto colgó inesperadamente
Así que la operación de clonación git falló. Me pregunto por qué intenta inicializar un repositorio de git vacío en el directorio de mi usuario local (/ home / wyx)? Y como ya he agregado el id_rsa.pub del usuario local en .ssh / authorized_keys, ¿por qué todavía pide una contraseña?
Esto es lo que me solucionó el problema (en Ubuntu):
git clone [email protected]:/srv/gitosis/repositories/gitosis-admin.git
Finalmente lo puse funcionando asi
git clone ssh://git@host:1337/home/git/repositories/gitosis-admin.git
donde 1337 el puerto ssh está utilizando.
Gitosis crea su propio archivo authorized_keys . Si ya tiene ese archivo, elimínelo y permita que gitosis-init lo vuelva a crear. Una vez hecho esto, no te metas con el archivo.
Habiéndome movido a una nueva máquina Ubuntu y encontré esta pregunta, vi un par de respuestas aquí que me hicieron avanzar en la dirección correcta, es decir, usar una ruta absoluta a los archivos .git para cada repositorio.
Experimentando un poco noté que las rutas relativas al directorio de inicio del usuario git también funcionaban, lo que acortaba algo como:
git@host:/var/git/repositories/project.git
Abajo a
git@host:repositories/project.git
Jugando un poco más, intenté mover los archivos del proyecto desde los repositorios directamente al directorio principal de git; ahora solo se requiere el proyecto:
git@host:project.git
Es un poco hacky, pero dudo que cause ningún daño. Sería bueno saber qué cambió, ya que estaba alojando gitosis en otro Ubuntu (más antiguo) y pude tener los proyectos dentro del directorio de repositorios con la última notación de arriba.
La edición de authorized_keys no debería ser necesaria normalmente.
Una vez tuve un problema de autorización, el servidor de gitosis seguía pidiéndome una contraseña, incluso si antes había colocado mi clave pública. Me di cuenta de que la gitosis me dio una advertencia "ADVERTENCIA: gitosis.ssh: Nombre de usuario SSH inseguro en el archivo de claves: ''[email protected]''" cuando intenté confirmar y enviar mis cambios a la gitosis.
Cambiar la parte de usuario @ host en el archivo de claves y el nombre del archivo resuelto mi problema. De alguna manera a la gitosis no le gustó la anterior.
Para obtener más información sobre los problemas de autenticación, recopile detalles detallados del registro de depuración: mediante el uso de un
ssh -vvv gitosis@gitosis_host
truco de conexión manual directa (que, expresado de manera más importante / generalmente, en realidad usa la referencia de contexto más precisa / directa; en este caso: mecanismos ssh reales en lugar de herramientas distantes, y por lo tanto, menos precisas, ¡manejo de git!).
Resolví un problema similar. Puede que no sea exactamente lo que está sucediendo en su caso, pero podría intentar volver a aplicar la misma solución de problemas que hice.
Me di cuenta de que cuando presionaba las teclas para un nuevo usuario recibía este seguimiento de pila, que es el síntoma de que el gancho en la gitosis no pudo procesar la nueva clave.
remote: Traceback (most recent call last):
remote: File "/usr/local/bin/gitosis-run-hook", line 9, in <module>
remote: load_entry_point(''gitosis==0.2'', ''console_scripts'', ''gitosis-run-hook'')()
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/app.py", line 24, in run
remote: return app.main()
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/app.py", line 38, in main
remote: self.handle_args(parser, cfg, options, args)
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/run_hook.py", line 81, in handle_args
remote: post_update(cfg, git_dir)
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/run_hook.py", line 45, in post_update
remote: config=cfg,
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/gitdaemon.py", line 95, in set_export_ok
remote: for (dirpath, repo, name) in walk_repos(config):
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/gitdaemon.py", line 72, in walk_repos
remote: assert ext == ''.git''
remote: AssertionError
El error solo se mostraba UNA VEZ , por lo que ingenuamente lo descarté como un fallo momentáneo.
En la práctica, Gitosis trabajaba solo para mi clave, pero no funcionaba para ninguno de los usuarios que intentaba admitir. En ~/.ssh/authorized_keys no pude encontrar la clave pública del usuario que pensé que acababa de agregar. Es por eso que a mi amigo le pedían una contraseña cada vez que intentaba clonar.
Agregué la depuración a la configuración de Gitosis, agregando estas dos líneas a gitosis.conf
[gitosis]
loglevel=DEBUG
Tenía que seguir agregando y eliminando usuarios al archivo gitosis.conf para que el enlace se activara de nuevo. Mi registro de depuración revelado
remote: DEBUG:gitosis.gitdaemon:Deny ''syncShare''
remote: DEBUG:gitosis.gitdaemon:Walking ''legacy.d'', seeing [''buildtools'', ''QA_Dashboard'']
remote: DEBUG:gitosis.gitdaemon:Walking ''legacy.d/buildtools'', seeing [''.git'', ''conf'', ''scripts'']
remote: Traceback (most recent call last):
etc ...
A-ha! A medida que el gancho realizaba el "paseo" a través del repositorio, había encontrado un directorio .git bajo legacy.d/buildtools y ahí es exactamente donde se produjo el legacy.d/buildtools assert ext == ''.git'' .
Había usado el servidor para almacenar un clon simple de algún otro repositorio. Note, un clon simple, no un espejo o un repositorio simple. Como cada clon contenía el directorio .git.
El gancho en Gitosis no sabe qué hacer con un directorio .git. Piensa que es un repositorio en un nombre vacío y aborta. Una vez que borré ese clon, todo volvió a funcionar bien.
Se creó un repositorio vacío porque así es como funciona git: tiene que iniciar un repositorio antes de poder comenzar a arrastrar objetos remotos. Desafortunadamente, esto significa que tendrá que eliminar manualmente el repositorio vacío antes de intentar clonar nuevamente.
En cuanto a por qué falló el clon, parece que está usando la sintaxis incorrecta para la ruta del repositorio remoto; git clone no usa la sintaxis de scp. De hecho, si no especifica un protocolo de clonación, creo que asume el protocolo git en lugar de ssh, que probablemente sea la razón por la que le pidió una contraseña. Intenta esto en su lugar:
$ git clone ssh://gitosis@host/~/gitosis-admin.git
También enfrenté el mismo problema "fatal: ''/gitosis-admin.git'' no parece ser un repositorio válido". Busqué mucho por el problema y finalmente encontré la solución.
En realidad, la dirección predeterminada del usuario de gitosis es "/ srv / gitosis": como en el caso de que mi configuración tenga un servidor ubuntu 10.04.
Y cuando escribimos "git clone [email protected]: gitosis-admin.git", busca el repositorio gitosis-admin.git en / srv / gitosis. Así que cuando entré en el / srv / gitosis, descubrí que hay otro repositorio dentro de él llamado repositorios que consiste en el repositorio gitosis-admin.git.
Así que en realidad, por defecto, gitosis-admin.git no estaba en la ubicación predeterminada. Así que tengo que modificar la ruta de comando y luego funcionó bien.
Obtuve el repositorio clonado en mi máquina local. Utilicé el comando como:
"git clone [email protected]: repositorios / gitosis-admin.git" y funcionó bien para mí.
Consulte el directorio gitosis-admin en su caso y espero que pueda resolver su problema.
Tuve el mismo problema en Ubuntu,
Funcionó con git clone ssh://git@serverName/absolutePath/gitosis-admin.git