Las keys de GitLab SSH dejaron de funcionar

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 :

  1. Asegúrate de que sidekiq esté ejecutándose . Las keys se agregan a gitlab-shell en un trabajador de Sidekiq, por lo que si Sidekiq está inactivo o retrasado, no lo harán. Puedes verificarlo en la salida de ps -fu git y marcando la pestaña "trabajos en segundo plano" en la página de administración.
  2. Asegúrese de que GitLab pueda ejecutar gitlab-shell correctamente. El trabajador de Sidekiq agrega keys ejecutando un 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.
  3. Verifique que la partición del server / inicio no esté llena. Si el disco en el que está almacenado el file 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.

Intereting Posts