GitLab requiere contraseña de git @ localhost para enviar a un repository

Estoy intentando poner en funcionamiento GitLab en mi server. Seguí las instrucciones de installation en la página gitlab gitlab y todo salió bien.

El problema es cuando creo un repository e bash

sudo git push -u origin master 

Se me solicita la contraseña de 'git @ localhost:'

El usuario de git no tiene una contraseña, entonces esto es un problema.

Otras personas que se han encontrado con este problema sugirieron agregar git a AllowedUsers en mi sshd conf, pero no tengo un campo AllowedUsers allí, por lo que no parece ser un problema.

Todavía soy bastante nuevo en ssh, así que creo que es una especie de problema key ssh, aunque traté de agregar todas las keys ssh relevantes a /home/git/.ssh/authorized_keys y verifiqué que no hay saltos de línea en el file .

Solo para tu información, mi installation pasa completamente la testing provista en la wiki de gitlab:

 sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production 

Cualquier sugerencia muy apreciada!

EDITAR

Entonces, finalmente solucioné esto simplemente comprometiéndome con un repository de una máquina diferente. Tal como estaban las cosas, me SSHed en la misma máquina en la que se estaba ejecutando gitlab. Tan pronto como traté de comprometerme desde una máquina que no sea el host, funcionó de maravilla. Entonces, esa puede ser una solución para algunas personas (es para nosotros, ya que desarrollamos en máquinas separadas que nuestros serveres).

Este sigue siendo un problema abierto para cualquiera que intente hospedarse y desarrollarse en la misma máquina que se ha topado con esto.


TL; DR

Las keys se almacenan tanto en el DB gitlab como en el lado de la gitolita. Deberías utilizar la carpeta build de fábrica gitolite-admin.git, ¡no uses tu copy de security! Y reconstruya las keys para gitolite más tarde con el command de las teclas de actualización. (actualice esas keys ya guardadas dentro de gitlab db a gitolite)

 sudo -u gitlab -H bundle exec rake gitlab:gitolite:update_keys RAILS_ENV=production 

Lo más probable es que haya algún problema con las keys de gitolite que no se guardan correctamente. Esas keys (para iniciar session) en realidad se guardan por separado por gitlab y gitolite. Para tirar / empujar en realidad está usando las teclas guardadas dentro de gitolite. (git / repositories / gitolite-admin.git / index, git / .gitolite / keydir, git / .ssh / authorized_keys)

gitlab normalmente debería ayudar a save esas keys importadas en la web a los files gitolite. Sin embargo, por alguna razón falló. Como las keys no se guardan correctamente dentro de gitolite, el cliente / server no puede usar las teclas y volver a la contraseña.

Debe verificar y corregir las keys guardadas dentro de gitolite para corregir los problemas.

echa un vistazo para get más https://groups.google.com/forum/?fromgroups=#!topic/gitlabhq/X0z_9l7L7A8

Si la installation fue bien, eso significa que tu gitlab puede clonar el repository de gitolite-admin sin problemas.
Pero dices que pasa la verificación de estado, lo que significa que estás usando, para la connection ssh, una count llamada 'gitlab'.

Eso también significa que cualquier cliente tendrá que gitlab ssh con la misma count ' gitlab ', no ' git '.
Entonces, si su key ssh ha sido agregada a través de la interfaz gitlab, entonces puede hacer clit / git push a un origen de nombre remoto que tendría la dirección ' gitlab@server '

Para depurar un poco más, consulte algunos otros consejos mencionados en " Configuración de Git Remote SSH (git-upload-pack / git-receive-pack) ":

Si no puede presionar localmente (en el server, es decir, en 'localhost'), intente al less a:

 ssh -vvvT gitlab@localhost 

No debería requerir ninguna contraseña, ya que /home/gitlab/.ssh/id_rsa y /home/gitlab/.ssh/id_rsa.pub existen ambos.

Recibí el mismo aviso de contraseña. Mi problema era que había restringido el uso de ssh a solo un par de usuarios. Agregué el usuario de git a la list AllowUsers sshd_config, y todo funcionó de maravilla.

Asegúrate de que tu perfil gitlab tenga tu key pública ssh. Inicie session en gitlab, vaya a su perfil y select el button "Agregar key pública". Copie y pegue el contenido ".fub" del file "keyfile" en el cuadro Clave. Hubo algunas versiones de gitlab que tenían un error que cuando agregabas tu key pública, no actualizaba el file authorized_keys. Verifique (pero no agregue manualmente) que su key pública está en el file authorized_keys luego de agregarla a su perfil. Si este no es el problema, tal vez una de las respuestas anteriores ayude.

en el server de git edite /etc/ssh/sshd_config

elimine las siguientes líneas de la sección de authentication o agréguelas:

PubkeyAuthentication yes

AuthorizedKeysFile %h/.ssh/authorized_keys

dale a tu server un ciclo de encendido y luego enciende el gitlab

Me encontré con un problema que exhibía síntomas similares. Mi problema es que tengo dos computadoras detrás de un enrutador. El enrutador está configurado para reenviar el tráfico SSH (puerto 22) a la computadora 1. Gitlab está instalado en la computadora 2. Estoy usando un dominio y una IP pública para conectarme. Cuando presiono, el tráfico de SSH se dirige a la computadora 1. Hay un usuario de git en la computadora 1 simplemente por haber instalado git. La computadora 1 me pide la contraseña del usuario de git.

Mi installation también pasó todos los controles listos.

No estoy seguro de si tiene el mismo problema, pero los síntomas son los mismos, así que pensé que esto podría ayudar.

Esto comenzó a pasarme bastante últimamente: para proyectos de trabajo, git me preguntaba mi correo electrónico y mi contraseña. Cuando se ingresa, continúa bien pero es molesto.

Puedo arreglar esto para cualquier aplicación dada a la que tenga acceso:

 git config remote.origin.url git@github.com:user_org_or_co/repo_name_itself 

p.ej

 git config remote.origin.url git@github.com:smithw/bookmarkapp 

¿Tus usuarios de gitlab y gitlab no tienen contraseña?

¿Cómo es el sshd_config ?

compruebe si esta línea está en el file: PermitEMptyPassword Yes

De todos modos, supongo que es inseguro, en mi installation, puse este 'Sí', clono y luego guardo la configuration anterior … Cuando clona la ssh_key es guardada por el usuario git, y ya no me pide contraseña.

Pero ahora, me encuentro con otro error, cuando voy a presionar, para cada nuevo Usuario, tenemos que volver a configurar ssh para permitir el permiso de vaciar y luego mantener la configuration.

(Todavía no he probado este método, porque descubrí que mi gitlab no está creando los repos en el usuario de git: /)

Esto puede ser demasiado simple, pero tuve el mismo problema. Supongo que es porque recogió localhost como el nombre de dominio.

Funcionó cuando me conecté desde otra computadora a mi máquina localhost, y luego intenté comprometerme. Es bastante tonto, pero vale la pena intentarlo.

Me confundí con esto una vez. Cuando usas sudo git , eso significa que el git se inicia como root. La pregunta sería: ¿crearon la key SSH para root y la colocaron dentro de Gitlab?

Supongo que creó su key SSH sin sudo (que es para su count normal), puso la key pública SSH en Gitlab y luego ejecutó sudo git .

Puedes intentar ejecutar git sin el sudo . Y si tienes problemas con el permiso de la carpeta, que te hizo usar sudo en primer lugar, intenta darle acceso a esa carpeta a tu count de usuario. O quizás pruebe el git normalmente en una carpeta que tenga permiso de escritura.

Hay un ticked para eso aquí .

Para determinar la causa del problema, verifique los loggings en el server a través de sudo grep sshd /var/log/auth.log .

Hasta el 13 de diciembre de 2013 commit b24d5d , el problema se produjo en la máquina de desarrollo Vagrant debido a un exceso de permissions para .ssh/ . Debes tener:

 chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys 

o ssh se niega a hacer la connection rsa y sudo grep sshd /var/log/auth.log dice:

 Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys 

El problema se ha resuelto estableciendo sshd en modo no espectral para el desarrollo, lo que permite que se ejecute correctamente incluso si los permissions son demasiado gratuitos.

Esto significa que el server gitlab ssh no se configuró correctamente.

Edite /etc/ssh/sshd_config y asegúrese de que:

 PasswordAuthentication no ChallengeResponseAuthentication no 

Esto debería hacer cumplir ssh key solo inicios de session que también es una buena medida de security. Muchas distros más nuevas ya tienen esto habilitado por defecto.

No me pregunte si se bloquea fuera, claramente ASÍ NO es el lugar donde preguntar cómo configurar y usar un par de keys privadas / públicas.

Me encontré con el mismo problema recientemente, y descubrí que el problema para mí era que SELinux impedía que sshd accediera al file authorized_keys en el directory de datos de gitlab /var/opt/gitlab/ .

Para solucionar esto, edite /etc/selinux/targeted/contexts/files/file_contexts.homedirs y agregue la línea:

 /var/opt/gitlab/\.ssh/.* system_u:object_r:ssh_home_t:s0 

Entonces corre:

 $ restrecon -Rv /var/opt/gitlab 

Fuente: https://serverfault.com/questions/50573/selinux-preventing-passwordless-ssh-login

Para cualquier persona que tenga este problema con Bitnami o cualquier otra configuration que quiera resolverlo rápidamente, simplemente use la ruta completa.

 git clone git@server_adress:/full/path/to/project.git 

editado: olvidé mencionar, es muy importante verificar si ha agregado las keys SSH a git-lab a través de la página web.