Instalé gitolite3 desde el repositorio EPEL en Centos6.4. Había una serie de cosas que no me gustaban, así que me propuse cambiarlas. Primero, creé un usuario y un grupo adicional llamado 'git' para distanciarme del oscuro usuario gitolite3. En segundo lugar, utilicé una carpeta personalizada /Servidor/Proyectos en lugar de /var/lib/gitolite3. Me aseguré de que la propiedad y los permisos fueran los mismos.
La configuración tampoco tuvo problemas (su - git, luego configuración de gitolite3 con la clave del cliente de administrador).
Normalmente, en una máquina cliente, el comando ssh git@myserver infogeneraría un bonito retorno simple de gitolite que enumera los repositorios y los permisos. Pero ahora me pide una contraseña. Obviamente, gitolite ya no está conectado al puerto ssh a través de este usuario, pero el bash habitual sí.
No soy un experto en SSH, entonces algo salió mal o olvidé hacer algo. ¿Dónde debería buscar? Creo que /usr/share/gitolite3/gitolite3-shell es la aplicación a la que SSHD debería llamar cuando llega una solicitud SSH con el usuario de git.
Respuesta1
SSH no es fácil. Lo resolví yo mismo, pero no era obvio. Fue principalmente un problema de SELinux, pero descubrí que tampoco había configurado la clave pública correctamente.
Primero, (re)creé la clave pública (admin.pub) para la computadora local que iba a administrar el servidor gitolite, la copié en la carpeta de inicio del usuario git del servidor, volví a ejecutar (bajo el usuario git en su carpeta de inicio) el gitolite. configurar con esa clave pública. Una nota aquí es que mi computadora local tiene Windows con msys-git, lo que hace que el problema no sea fácil.
# su - git
$ cd /Server/Projects
$ gitolite setup --pubkey admin.pub
..Eso resolvió el problema de la clave pública. Selinux fue una curva de aprendizaje más grande, pero esencialmente se pierden todas las etiquetas de contexto de la carpeta /var/lib/gitolite3 originales cuando simplemente se copia. Para restaurar las etiquetas (con semanage), haga referencia a las mismas etiquetas (con el indicador -e) que en la carpeta original, donde configuró la carpeta gitolite actual. Dado que eso solo se suma a los contextos de archivos selinux existentes, también necesita restaurarlos desde los contextos de archivos selinux. El último problema es utilizar rutas absolutas, no rutas relativas. Puedes ver lo que hiciste con el comando ll:
# semanage fcontext -a -e /var/lib/gitolite3 /Server/Projects
# restorecon -R /Server/Projects
# ll -aZ
Ahora, en su máquina local, pruébelo todo con el siguiente comando desde la computadora de donde provenía la clave pública, funcionó para mí. Tenga en cuenta que no sabía que eso ssh git@unclefloserver infosolo devolvería una buena salida de información del repositorio de gitolite3 si el servidor realmente tiene la clave pública de la combinación de usuario/computadora solicitante. Tampoco entendí un poco este concepto y estaba probándolo desde una computadora diferente.
> git clone git@server:gitolite-admin
Muchas gracias a @Etan Reisner por mantener la presión alta.