software sitio oficial lab git ssh gitolite gitlab

sitio - login git bash



GitLab requiere la contraseƱa de git @ localhost para ingresar a un repositorio (14)

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

¿Cómo es el sshd_config ?

verifique si esta línea está en el archivo: PermitEMptyPassword Yes

De todos modos, supongo que es inseguro, en mi instalación, puse este ''Sí'', cloné y luego conservé la configuración antigua ... Cuando el clon guarde la tecla ssh, el usuario la guardará y no volverá a pedir la contraseña.

Pero a estas alturas, me encuentro con otro error, cuando voy a presionar, para cada nuevo Usuario, tenemos que reconfigurar ssh para permitir el empuje vacío y luego mantener la configuración.

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

Estoy intentando que GitLab esté funcionando en mi servidor. Seguí las instrucciones de instalación en la página de gitub de gitlab y todo salió bien.

El problema es que cuando creo un repositorio y trato de

sudo git push -u origin master

Me piden la contraseña de ''git @ localhost:''

El usuario de git no tiene una contraseña, por lo que este 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 ahí, por lo que no parece ser un problema.

Sigo siendo bastante nuevo en cosas de ssh, así que creo que es un problema de clave ssh, aunque intenté agregar todas las claves ssh relevantes a /home/git/.ssh/authorized_keys y verifiqué que no hay saltos de línea en el archivo .

Solo para su información, mi instalación pasa completamente la prueba provista en el wiki de gitlab:

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

Cualquier sugerencia muy apreciada!

EDITAR

Entonces, finalmente resolví esto simplemente comprometiéndome con un repo de una máquina diferente. Tal como estaba, fui SSHed en la misma máquina en la que se estaba ejecutando gitlab. Tan pronto como intenté cometer desde una máquina que no era el host, funcionó muy bien. Entonces, esa puede ser una solución para algunas personas (es para nosotros, ya que desarrollamos en máquinas separadas que nuestros servidores).

Este es todavía un problema abierto para cualquiera que intente alojar y desarrollar en la misma máquina que se ha encontrado con esto.


Asegúrese de que su perfil de gitlab tenga su clave pública ssh. Inicie sesión en gitlab, vaya a su perfil y seleccione el botón "Agregar clave pública". Copie y pegue los contenidos de .pub del "archivo de claves" en el cuadro Clave. Hubo algunas versiones de gitlab que tenían un error que cuando agregabas tu clave pública, no actualizaba el archivo authorized_keys. Verifique (pero no agregue manualmente) que su clave pública está en el archivo authorized_keys después de agregarla a su perfil. Si este no es el problema, tal vez una de las respuestas anteriores ayude.


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

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

git config remote.origin.url [email protected]:user_org_or_co/repo_name_itself

p.ej

git config remote.origin.url [email protected]:smithw/bookmarkapp


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

Funcionó cuando inicié sesión desde otra computadora en mi máquina localhost y luego intenté confirmar. Es bastante tonto pero vale la pena intentarlo.


Esto significa que el servidor gitlab ssh no fue configurado correctamente.

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

PasswordAuthentication no ChallengeResponseAuthentication no

Esto debería imponer el inicio de sesión solo con la clave ssh, lo que también es una buena medida de seguridad. Muchas distribuciones nuevas ya tienen esto habilitado de forma predeterminada.

No me preguntes si te bloqueas afuera, claramente SO no es el lugar donde preguntar cómo configurar y usar un par de claves privada / pública.


Hay un tic tac para eso here .

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

Hasta el 13 de diciembre de 2013, se confirma b24d5d , el problema se originó en la máquina de desarrollo Vagrant debido a un exceso de permisos para .ssh/ . Usted debe tener:

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

o ssh se niega a hacer la conexión 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 resolvió configurando sshd en modo no sctrict para el desarrollo, permitiéndole que se ejecute correctamente, incluso si los permisos son demasiado libres.


Me confundí con esto una vez. Cuando usas sudo git , eso significa que el git se está iniciando como root. La pregunta sería: ¿creaste la clave SSH para root y la pusiste dentro de Gitlab?

Supongo que creó su clave SSH sin sudo (que es para su cuenta normal), coloque la publicación SSH en Gitlab y luego ejecute sudo git .

Puedes intentar ejecutar git sin el sudo . Y si tiene problemas con los permisos de carpeta, lo que hizo que usara sudo en primer lugar, intente darle a su cuenta de usuario acceso a esa carpeta. O tal vez intente el git normalmente en una carpeta que tenga permiso de escritura.


Me encontré con el mismo problema recientemente, y descubrí que el problema para mí era que SELinux estaba impidiendo que sshd acceda al archivo authorized_keys en el directorio de datos de gitlab /var/opt/gitlab/ .

Para solucionarlo, 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:

$ restorecon -Rv /var/opt/gitlab

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


Me encontré con un problema que mostraba síntomas similares. Mi problema fue 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 conectar. Cuando empujo, el tráfico 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 git.

Mi instalación también pasó todas las comprobaciones listas.

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


Para cualquier persona que tenga este problema con Bitnami o cualquier otra configuración que quiera resolverlo rápidamente, solo 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 claves SSH a git-lab a través de la página web.


Recibí la misma solicitud de contraseña. Mi problema era que había restringido el uso de ssh a solo un par de usuarios. Agregué el usuario git a la lista de usuarios permitidos sshd_config, y todo funcionó muy bien.


Si la instalación se realizó correctamente, eso significa que su gitlab puede clonar el repositorio de gitolite-admin sin ningún problema.
Pero usted dice que pasa la verificación de estado, lo que significa que está usando, para la conexión ssh, una cuenta llamada ''gitlab''.

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

Para depurar un poco más, echa un vistazo a algunos otros consejos mencionados en " Configurar Git Remote SSH (git-upload-pack / git-receive-pack) ":

Si no puede enviar de forma local (en el servidor en sí, es decir, en ''localhost''), intente al menos una:

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 .


TL; DR

Las llaves se almacenan tanto en gitlab DB como en gitolite side. Debe usar la carpeta de creación de gitolite-admin.git de fábrica, ¡no use su copia de seguridad! Y reconstruye las Claves para gitolite más adelante con el comando actualizar claves. (Actualice las claves ya guardadas en la base de datos de gitlab a gitolite)

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

Lo más probable es que haya un problema con las claves de gitolite que no se guardan correctamente. Esas claves (para iniciar sesión) en realidad se guardan por separado por gitlab y gitolite. Para pull / push es en realidad usar 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 guardar las claves importadas en la web en los archivos de gitolite. Sin embargo, por alguna razón falló. Como las claves no se guardan correctamente dentro de gitolite, el cliente / servidor no puede usar las claves y no puede utilizar la contraseña.

Debe corregir y corregir las claves guardadas en gitolite para corregir los problemas.

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


en el servidor git edite /etc/ssh/sshd_config

descomente las siguientes líneas en la sección de autenticación o agréguelas:

PubkeyAuthentication yes

AuthorizedKeysFile %h/.ssh/authorized_keys

dale a tu servidor un ciclo de energía y luego enciende gitlab