¿Qué "derechos de acceso" podrían estar bloqueando el acceso a un repositorio de gitlab?

14

Estoy tratando de configurar gitlab (6.5.1) en un servidor nuevo y limpio. Todo parece funcionar, pero git no puede impulsar ningún proyecto. Seguir los comandos de la página del proyecto recién creado y presionar el control remoto a través de ssh proporciona:

$ git push -u origin master
fatal: Could not read from remote repository.

Please make sure you have the correct access
rights and the repository exists.

Esto parece ser un problema bastante común. Desafortunadamente, parece tener varias causas potenciales y ninguna de ellas parece coincidir. Desde el número 3424 en una versión anterior y varias otras fuentes en línea, he visto y verificado las siguientes sugerencias:

  • Sobrantes teclas ssh

    Esta es una configuración limpia sin restos. Mi clave se agregó correctamente al archivo de claves autorizadas y es la única listada.

  • La ejecución de ssh con registro de depuración muestra errores relacionados con los vars del entorno Ruby.

    El mío sale limpio. La depuración SSH muestra una conexión exitosa. Todo sobre el protocolo de enlace de autenticación es normal, entonces este es el final de la salida:

    debug1: Sending command: git-receive-pack 'username/reponame.git'
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK

  • Problemas con el entorno gitlab-shell.

    A diferencia de muchos otros con el mismo mensaje de error anterior, mi secuencia de comandos de verificación gitlab-shell devuelve un estado de salud limpio:

    % sudo -u gitlab -H ~gitlab/gitlab-shell/bin/check   
Check GitLab API access: OK
Check directories and files: 
        /var/lib/gitlab/repositories: OK
        /var/lib/gitlab/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.8.5
Send ping to redis server: PONG

  • Reiniciar {unicornio, sidekiq, redis}

    Los informes de que reiniciar uno o más servicios aclaran esto no parecen aplicarse aquí. Este no es un problema intermitente que corrige la liberación de un demonio.

  • El repositorio no se está creando físicamente

    Pero es. La primera vez cada vez, el repositorio de git desnudo ~gitlab/repositories/username/reponame.gitse crea cada vez y parece tener los permisos correctos.

  • Gitlab-shell no puede hablar con el servidor API porque A) problemas de DNS, B) enlace incorrecto de ip / puerto / interfaz C) no tener / tener una barra inclinada final.

    El script de verificación dice que el acceso a la API está bien.

    No estoy ejecutando nginx, por lo que el problema de enlace de ip predeterminado relacionado con eso es n / a.

    He intentado ambos *:8080y 127.0.0.1:8080por el valor de escuchar en unicorn.yml.

    Más allá de eso, he intentado varias iteraciones de localhost, 127.0.0.1 y el nombre de dominio completo (que está resolviendo bien el DNS) con y sin barras diagonales finales en shell.ymlvano. También he intentado conectar esto directamente al servidor unicornio en el puerto 8080 en lugar del host Apache SSL / proxy en el puerto 80. Nada parece hacer ninguna diferencia. Mi certificado no está autofirmado y funciona bien para los navegadores, pero intenté configurarlo de self_signed_cert: truetodos modos. Nada.

  • Las rutas de acceso de git informadas son incorrectas, agregue una ruta totalmente calificada desde el inicio del usuario de gitlab.

    Esto parece una sugerencia legítima si gitlab-shell no está haciendo algunos negocios de monos para corregir esto, pero intenté cambiar git remote add origin gitlab@server:username/reponame.gita `` git remote add origin gitlab @ server: repositories / username / reponame.git` en vano. Mismo error.

Esta parece ser la letanía de soluciones sugeridas, pero ninguna de ellas parece correcta. Tenga en cuenta que puedo empujar sobre http. La solicitud de inicio de sesión acepta mi nombre de usuario y contraseña de ldap y acepta una inserción. Esto es solo un problema al intentar usar SSH. Probar solo la parte de inicio de sesión ssh ssh -T gitlab@serverfunciona bien.

¿Qué más podría estar causando este error?

¿Cómo se puede depurar un problema de este tipo en gitlab? No parece haber nada relevante en absoluto en ~gitlab/gitlab-shell/gitlab-shell.log. ¿Dónde se encontraría un mensaje de error más informativo?

git arch-linux server-setup gitlab Caleb
fuente
¿Cuál es el resultado de: "ssh -vv gitlab @ server" ??
DrGkill
@DrGkill Nada interesante (a mis ojos), compruébalo por ti mismo .
Caleb
Vea en su sshd_config si gitlab está permitido para el inicio de sesión externo. Yo diría 2 posibles culpables: SSH o gitlab-shell. ¿Qué dice auth.log cuando gitlab se conecta?
DrGkill
@DrGkill Lo he comprobado (y si no se permitiera el inicio de sesión externo mediante sshd o pam, los registros que le mostré anteriormente no habrían mostrado un aviso de autenticación exitoso). SSH se conecta muy bien. Los registros del lado del servidor muestran una autenticación exitosa, que se abrió una sesión, algunas cosas del sistema sobre la configuración del entorno del usuario, luego "se desconectó de <ip remota>" y algunas cosas más sobre la limpieza de la sesión.
Caleb

Respuestas:

7

Estoy bastante seguro de que tiene un problema de configuración entre SSH y el sistema debido a este mensaje de depuración SSH:

client_input_channel_req: channel 0 rtype [email protected] reply 0

Recibirá este mensaje inmediatamente después de una autenticación exitosa y ningún mensaje de bash, lo que significa que no se inició ningún programa después de iniciar sesión.

Mire en su archivo passwd si tiene la configuración correcta para el usuario de gitlab:

gitlab:x:1011:1012:GitLab,,,:/path/to/gitlab:/bin/bash

Verifique que bash no tiene nada extraño en los archivos de configuraciones como

  • bash.bashrc
  • .perfil
  • .bashrc

Luego suba al nivel superior: Gitlab-shell Verifique que /path/to/gitlab/.ssh/authorized_keys tenga la siguiente configuración:

command="/path/to/gitlab/gitlab-shell/bin/gitlab-shell key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa A...

con / ruta / a / gitlab / gitlab-shell / bin / gitlab-shell propiedad del usuario gitlab y ejecutable.

Puede estar seguro de que gitlab-shell está completamente operativo al iniciar el comando:

# /path/to/gitlab-shell/bin/gitlab-shell
Welcome to GitLab, Anonymous!

Si el inicio de sesión remoto realmente funciona y está conectado correctamente al gitlab-shell, debería recibir el mismo mensaje de bienvenida (pero que coincida con el usuario cuya clave ssh usó para iniciar sesión) antes de que lo rechace si intenta iniciar sesión de forma remota.

$ ssh gitlab@server
Welcome to GitLab, <your user's full name>!
Connection to <server> closed.

Ningún mensaje aquí probablemente indica que ssh no lo está conectando a gitlab en absoluto.

Finalmente, verifique su configuración de gitlab-shell (config.yml) y verifique si:

http_settings:
    # trailing slash is important
    gitlab_url: "https://remote_server/"
    ca_file: /path/to/webserver/certificate.crt

y eventualmente:

    self_signed_cert: false
DrGkill
fuente
Doh <head-desk> Estuviste en el camino correcto todo el tiempo. El usuario de gitlab estaba siendo asignado /bin/false. O bien el paquete Arch no establece el shell correctamente al agregar ese usuario o lo rompí en algún lugar del proceso de implementación de la autenticación ldap en este sistema. Gracias por todo el esfuerzo.
Caleb
Ty por respuesta, me ayudó a depurar. Otro problema es que cuando tiene habilitado el reenvío de claves ssh, envía la clave incorrecta a gitlab que no puede identificarlo. Cuando ingrese a gitlab, también recibirá Welcome Anonymous. Simplemente deshabilite el reenvío de claves en su servidor con ssh -a
tommics
Tuve el mismo problema que Caleb, y también descubrí por mí mismo que para que funcione, es necesario establecer un shell en lugar de / bin / {false, true, nologin}. Pero en realidad el usuario se crea sin shell a propósito durante la instalación (ver: gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/… ) sudo adduser --disabled-login --gecos 'GitLab' git. Por lo tanto, debería funcionar sin una cáscara. Todavía estoy buscando otra solución.
Huygens
0

Tuve este mismo problema y después de días de buscar en Google y buscar Stack Overflow finalmente encontré mi problema. Quería poner esto por escrito conectado a Gitlab en caso de que alguien más tuviera el mismo problema.

Encontré mi solución aquí: /programming/17307154/git-bash-push-to-bitbucket-ignores-ssh-key

Estoy en Windows y el problema era que Git Bash estaba tratando de obtener su ubicación de clave SSH de plink.exe, que se instala con Putty.

La solución fue eliminar la variable de entorno GIT_SSH. Entonces todo funcionó.

Espero que esto ayude a alguien por ahí.

AllanT
fuente