Bien, he tropezado con este tema muchas veces, pero esta es la primera vez que ninguna de las soluciones regulares funcionó.
Tengo un server CentOS 6.4 ejecutando GitLab . Ha funcionado muy bien con más de 20 usuarios y más de 60 proyectos, pero hace aproximadamente 5 horas, mi server principal de transferencia no pudo conectarse a la máquina GitLab por primera vez con authentication de key y solicitó una contraseña. Regeneré la key RSA y la agregué a mis keys de implementación, pero eso también falló.
Luego, traté de crear un nuevo usuario en el server intermedio, crear una key para él y agregarlo a GitLab, pero aún falla.
Permisos:
drwxr-x--- 22 root root 4.0K Oct 28 13:20 root Raíz interna:
drwx------ 2 root root 4096 Oct 28 11:49 .ssh
Dentro de .ssh:
-rw------- 1 root root 227 Oct 28 11:48 authorized_keys -rw------- 1 root root 1675 Oct 28 13:09 id_rsa -rw------- 1 root root 398 Oct 28 13:09 id_rsa.pub -rw-r--r-- 1 root root 413 Oct 28 11:49 known_hosts
Cuando trato de conectarme a la máquina git:
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to git.mygitlab.com [212.29.122.24] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: loaded 3 keys debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'git.mygitlab.com' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with- mic,password debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No cnetworkingentials cache found debug1: Unspecified GSS failure. Minor code may provide more information No cnetworkingentials cache found debug1: Unspecified GSS failure. Minor code may provide more information No cnetworkingentials cache found debug1: Next authentication method: publickey debug1: Offering public key: /root/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with- mic,password debug1: Trying private key: /root/.ssh/identity debug1: Trying private key: /root/.ssh/id_dsa debug1: Next authentication method: password git@git.mygitlab.com's password:
Cuando agrego keys SSH a través de la interfaz web, no se agregan a .ssh/authorized_keys .
Realmente no sé qué probar a continuación 🙁
Si las keys que agrega a GitLab no lo hacen en .ssh/authorized_keys :
ps -fu git y marcando la pestaña "trabajos en segundo plano" en la página de administración. gitlab-shell . En particular, esto no funcionará si la configuration de ssh_user es incorrecta en gitlab.yml , o si gitlab-shell está instalado en una location que no sea ~/gitlab-shell para ese usuario. authorized_keys se llena, ¡la tecla se agrega con error! Este me ha conseguido algunas veces. Use df -h /home para ver si todavía tiene espacio. Verifique sus loggings de posts de error de gitlab-shell: dependiendo del problema, los posts de error podrían aparecer en los loggings de unicornio o sidekiq.
Bueno, ahora estoy debajo de 5.1 lo hice paso a paso 4.1> 4.2 4.2> 4.3 y, finalmente, todo está funcionando.
Solo para 4.1 usuarios saber -> uno de los desarrolladores agregó una key incorrecta que incluye la raíz $ # … y esto es lo que rompió la synchronization.
Gracias por tu ayuda
Acabo de encontrarme con este problema cuando cambié el server de GitLab de HTTP a HTTPS. Todo se veía bien en el server web: los inicios de session, etc. funcionaban normalmente, pero las conexiones SSH de git @ gitlab estaban fallando.
Después de mirar # 2 en http://sofes.miximages.com/a/19637026/2162639 (arriba) descubrí que necesitaba modificar la configuration de /home/git/gitlab-shell/config.yaml en /home/git/gitlab-shell/config.yaml para usar https://gitlab.server.fqdn lugar de http://gitlab.server.fqdn . Cambié esa configuration, reinicié el service gitlab y todo estaba funcionando normalmente.
Tuve que eliminar todas las keys anteriores para el host. El problema es que gitlab toma cualquier key anterior y si la coincidencia no existe, falla allí. Su key de trabajo se puede enumerar más adelante en order y nunca recogido.