Gitosis requiere contraseña aunque la clave pública se da

Question

me encontré con algunos problemas al intentar configurar gitosis en mi Archlinux

http://wiki.archlinux.org/index.php/Setting_Up_Git_ACL_Using_gitosis

me he referido a este artículo wiki y gitosis instalado con éxito.

$ sudo pacman -U gitosis-git-20090525-1-i686.pkg.tar.gz
$ sudo -u -H gitosis gitosis-init < /tmp/id_rsa.pub

Y modificó /srv/gitosis/.ssh/authorized_keys para incluir el ID_rsa.pub de mi usuario local.

Pero cuando corro git clone que el usuario local,

$ git clone gitosis @ host: gitosis-admin.git

Dice

ya iniciada repositorio vacío de Git en /home/wyx/gitosis-admin/.git/
contraseña de gitosis@10.132.140.73: *****
fatal: 'gitosis-admin.git' no parece ser un repositorio git
fatal: El extremo remoto colgó inesperadamente

lo que la operación git clone fallidos. Me pregunto por qué intenta inicializar un repositorio vacío de git en el directorio de usuario local (/ home/wyx). Y como ya agregué el id_rsa.pub del usuario local en .ssh/authorized_keys, ¿por qué todavía solicita una contraseña?

Answer 1

Se creó un repositorio vacío porque así es como funciona git: tiene que iniciar un repositorio antes de que pueda comenzar a introducir objetos remotos en él. Desafortunadamente, esto significa que tendrá que eliminar manualmente el repositorio vacío antes de volver a intentar clonar.

En cuanto a por qué falló el clon, parece que está utilizando una 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 el motivo por el que le pidió una contraseña. Tal vez puedas probar:

 
$ git clone ssh://gitosis@host/~/gitosis-admin.git 

Answer 2

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.

Answer 3

También me enfrenté al 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 mi configuración con el servidor de ubuntu 10.04.

Y cuando escribimos "git clone gitosis@server.com: gitosis-admin.git", busca el repositorio de gitosis-admin.git en/srv/gitosis.Entonces, cuando ingresé al/srv/gitosis, descubrí que hay otro repositorio dentro de él denominado repositorios que consiste en el repositorio gitosis-admin.git.

De hecho, de forma predeterminada, gitosis-admin.git no estaba en la ubicación predeterminada. Entonces tengo que modificar la ruta del comando y luego funcionó bien.

Tengo el repositorio clonado en mi máquina local. Utilicé el comando como:

"git clone gitosis@server.com: repositories/gitosis-admin.git" y funcionó bien para mí.

Consulte el directorio gitosis-admin en su caso y espero que pueda resolver su problema.

Answer 4

finalmente lo tengo trabajando así

git clone ssh://git@host:1337/home/git/repositories/gitosis-admin.git 

en 1337 el puerto ssh está utilizando.

Answer 5

Esto es lo que resuelve el problema para mí (en Ubuntu):

git clone gitosis@ns.home:/srv/gitosis/repositories/gitosis-admin.git 

Answer 6

que tenía el mismo problema en Ubuntu,

Se trabajó con git clone ssh://git@serverName/absolutePath/gitosis-admin.git

Answer 7

authorized_keys de edición no debería ser necesario normalmente.

Una vez tuve un problema de autorización, el servidor de gitosis me seguía preguntando la contraseña incluso si había colocado mi clave pública antes. Me di cuenta de que la gitosis me daba una advertencia "ADVERTENCIA: gitosis.ssh: nombre de usuario de SSH inseguro en el archivo de claves: 'myuser@myserver.pub'" cuando intenté enviar mis cambios a la glosis.

Al cambiar la parte user @ host en el archivo de clave y el nombre del archivo de clave resolví mi problema. de alguna manera la gitosis no le gustó la anterior.

Answer 8

El mismo problema, y ​​en mi caso fue que tenía autorización incorrecta en .ssh /. Debo haberlo estropeado en algún momento ...

Answer 9

Como me mudé a una nueva máquina Ubuntu y me encontré con esta pregunta, vi un par de respuestas que me ayudaron a avanzar en la dirección correcta, es decir, usar un ruta a los archivos .git para cada repositorio.

experimentando un poco me di cuenta de rutas relativas al directorio principal del usuario git también trabajó, que acortó algo como:

git@host:/var/git/repositories/project.git 

a

git@host:repositories/project.git 

jugar un poco más trataba de mover el proyecto archivos de repositorios directamente en el directorio de inicio 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 hospedando gitosis en otro Ubuntu (anterior) y pude tener los proyectos dentro del directorio de repositorios con la última anotación desde arriba.

Answer 10

Resolví un problema similar.Puede que no sea exactamente lo que está sucediendo en su caso, pero podría tratar de volver a aplicar la misma solución de problemas que yo.

Me di cuenta de que cuando estaba presionando teclas para un nuevo usuario estaba obteniendo esta stacktrace, 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 estaba mostrando solamente VEZ, por lo que ingenuamente lo descartó como un fallo momentáneo.

En la práctica, Gitosis solo funcionaba para mi llave, pero no funcionaba para ninguno de los usuarios que estaba tratando de admitir. En el ~/.ssh/authorized_keys no pude encontrar la clave pública del usuario que creía haber agregado. Esta es la razón por la cual a mi amigo siempre se le pedía una contraseña cada vez que intentaba clonar.

he añadido a la configuración de depuración Gitosis, mediante la adición de estas dos líneas a gitosis.conf

[gitosis] 
loglevel=DEBUG 

que tenía que seguir añadiendo y quitando los usuarios en el fichero de gitosis.conf manera que el gancho se pondría en marcha de nuevo. Mi registro de depuración reveló

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 "recorrido" a través del repositorio, había encontrado un directorio .git en legacy.d/buildtools y ahí es exactamente donde se produjo el assert ext == '.git'.

Había usado el servidor para almacenar un clon simple de algún otro repositorio. Aviso, un clon simple, no un espejo o un repositorio desnudo. Como cada clon, contenía el directorio .git.

El gancho en Gitosis no sabe qué hacer con un directorio .git. Cree que es un repositorio en un nombre vacío y aborta. Una vez que eliminé ese clon, todo volvió a funcionar bien.

Answer 11

Para obtener mayor conocimiento en cuestiones de autenticación, se reúnen prolijos detalles del registro de depuración: mediante el uso de un truco manual de conexión directa

ssh -vvv gitosis@gitosis_host

(el cual, su enunciado más importante/en general, en realidad utiliza la más precisa/referencia de contexto directa, en este caso: mecanismos ssh reales en lugar de la herramienta distante, y por lo tanto, menos precisa, manipulación git!).