tag - Gitolite One User-Many Keys-Diferentes nombres de usuario

git tag best practices (8)

La forma actual recomendada según la documentación

"Lo más simple y comprensible es poner sus claves en diferentes subdirectorios [dentro de su / kedir], (alice.pub, home / alice.pub, laptop / alice.pub, etc.)".

referencia: http://gitolite.com/gitolite/gitolite.html#multi-key

La vieja manera

Si está preguntando cómo logra lo siguiente:

David ( computadora personal )
David ( computadora de trabajo )
David ( computadora portátil )

Con diferentes claves ssh en cada computadora, simplemente cree la clave (es decir, keygen "[email protected]") y luego copie la clave pública en su directorio gitolite keydir (gitolite-admin / keydir). Cuando lo haga, simplemente nombre la clave [email protected] , [email protected] , y [email protected] . Agregue las claves al repositorio ( git add keydir/. ), git add keydir/. ( git commit -m "added David''s additional keys" ) y git push back al servidor.

Gitolite es lo suficientemente inteligente como para saber que, aunque es una clave diferente, el nombre de usuario (antes de @ ) sigue siendo david y permitirá que el usuario inicie sesión y use la ACL para david

Espero que esto ayude

Para arreglar un escenario donde podría tener john_home.pub john_work.pub abra su repositorio gitolite (repo de administración) y cambie el nombre de las claves en su kedir a [email protected] y [email protected] commit y presione. Ahora su usuario john puede iniciar sesión desde cualquier máquina y usar el mismo nombre de usuario.

Tenga en cuenta que, para que esto funcione, la dirección de correo electrónico en las claves SSH debe ser la misma para todas las claves del usuario. Entonces, usando el ejemplo anterior, en las teclas [email protected] , [email protected] , y [email protected] todos deben tener la dirección de correo electrónico [email protected] .

Arriba estaba la "vieja forma" de hacer esto y puede causar una complicación si usted ha nombrado sus llaves en la "dirección de correo electrónico" contrariamente a lo que dije anteriormente gitolite NO INSPECCIONA su clave para la dirección de correo electrónico correcta. Por favor ignore (dejé el comentario original para mayor claridad).

He configurado gitolite con suerte según las instrucciones, y todo está funcionando según lo planeado.

Estoy un poco inseguro sobre cómo funciona la parte de los nombres de usuario, y mirar a través de los documentos no me ha ayudado, quizás me esté perdiendo algo simple.

Si tengo dos máquinas cliente, para el uso de una persona real, pero en cada una de esas máquinas los nombres de usuario son, digamos dave y david. ¿Cómo puedo organizar las claves en keydir y cualquier archivo de configuración para que ambos representen al mismo usuario? Obtengo el sufijo, dave @ laptop, dave @ desktop (creo), simplemente no cómo tener diferentes nombres de usuario de máquinas cliente conectando, ya que parece buscar esto al autenticar (quizás debido a la clave pública que contiene información de usuario @ host) ?)

Si es necesario, puedo dar más detalles; simplemente no quería bombardearlos a todos con información irrelevante.

Muchas gracias.

Desde gitolite v3.5.2-10-g437b497 (septiembre de 2013, confirmar 59c817d0 ), existe una solución aún más simple:

ukm , para "administración de claves de usuario" .

La administración de claves de usuario permite a ciertos usuarios agregar y eliminar claves.

Puede introducir un nivel de delegación, cuando no solo el usuario administrador de gitolite puede agregar nuevas claves públicas ssh, sino que otros usuarios pueden hacerlo también.

También facilita agregar / eliminar claves públicas ssh.

Puedes verlo en acción en " contrib/t/ukm.t ":

La documentación de Gitolite incluye una sección sobre ese tema , pero con ukm , es más fácil (sección " Usuarios que desean administrar varias claves "):

Su administrador gitolite crea su identidad gitolite con una de sus claves como su clave inicial. Esta clave solo puede ser administrada por el administrador de gitolite, no por usted. Básicamente, determina bajo qué nombre se conoce gitolite.
Puede agregar nuevas claves a esta identidad y eliminarlas a su voluntad .

# The admin can add multiple keys for the same userid. try " ADDOK u5 admin u4/@example.org ADDOK u5 admin u4/@example.org/@home ADDOK u5 admin laptop/u4/@example.org ADDOK u5 admin laptop/u4/@example.org/@home ";

Gitolite realiza la autenticación con comandos forzados ssh. Todos los usuarios que tienen acceso a un repositorio de gitolite inician sesión cuando usan gitolite. Los ganchos toman nuevas claves en el teclado y las agregan a su archivo de claves autorizado configurado para usar comandos forzados.

Los usuarios se ven obligados a usar shell de gitolita con un parámetro, y ese parámetro es el nombre de usuario. La siguiente parte del gancho relevante toma la ruta del archivo y la asigna al usuario, luego quita todos los directorios y archivos con un / en el nombre. lo que quede de eso se convertirá en el nombre de usuario siempre que termine en .pub y .pub un solo signo @ que preceda al sufijo .pub , siempre que haya al menos un carácter adicional.

my $user = $f; $user =~ s(.*/)(); # foo/bar/baz.pub -> baz.pub $user =~ s/(/@[^.]+)?/.pub$//; # baz.pub, [email protected] -> baz

Esto proporciona funcionalidad como tal:

Los directorios son arbitrarios, pero para fines de organización los hosts se utilizan para dar estructura. Usted termina con dos usuarios de dave y un usuario de david .

Utilizo una configuración más como esta:

Nuevamente, la estructura del directorio no importa. Esto me da los usuarios [email protected] , jenkins , redmine y jira . El usuario de [email protected] tiene dos claves además del usuario de jenkins . Si tuviera más de un usuario, probablemente tendría un subdirectorio de usuarios que contenga el directorio de la clave steve.

Hay un punto sutil que parece que todos faltan aquí, o al menos no responden con claridad.

El OP preguntó cómo manejar la misma PERSONA utilizando dos USERNAMES diferentes y dos diferentes pub-keys (asociadas) en dos PLATAFORMAS diferentes.

P.ej. dave@platform_a.pub, y david@platform_b.pub representan al mismo usuario real de git.

Sería bastante fácil agregar a dave & david como usuarios en la línea "@known" (usuarios conocidos) en el archivo gitolite.conf, y poner ambas claves en el teclado, pero entonces no hay forma de saber si son dos usuarios separados, o la misma persona.

P.ej. "git blame" trataría a dave y david como dos usuarios separados.

Más allá de la publicación de OP, otra complicación es ¿qué sucede si hay varios David trabajando en el mismo proyecto?

Supongo que los Davids en cuestión tendrían que idear un sistema (o estar contentos de culparse entre ellos ;-).

He reorganizado mi clave de administración de gitolite un par de veces, y todavía no he decidido cuál es la mejor forma de organizar las cosas. Si puedes apegarte a algunas convenciones, las cosas serán más fáciles, pero eso no siempre es posible. Afortunadamente, la gitolita es flexible.

En general, prefiero no usar un único directorio plano que contenga todas las claves, confiando únicamente en la convención de nomenclatura "[email protected]" para mantener las cosas en orden. (¿Esto parece estar implícito en otras respuestas?). Esto puede volverse confuso si tiene múltiples claves en múltiples hosts y múltiples nombres de usuario para un solo usuario "real" (o incluso el mismo nombre de usuario para dos usuarios diferentes en dos hosts diferentes). Usar subdirectorios ayuda a organizar cosas, usando un árbol de cualquier profundidad, pero normalmente solo uso un nivel.

Las dos opciones principales (o incluso una combinación de las mismas):

un directorio por usuario "real", con cada directorio que contiene varias claves para ese usuario (por ejemplo, típicamente una por host).
un directorio por host (autorizado), con una (o más) claves por usuario que trabajarán en ese host. Aunque el usuario podría copiar su clave privada a otro host, eso (en mi caso) se desaconseja. En cualquier caso, los subdirectorios se nombran según el host donde se generó originalmente la clave.

Como ejemplo de un subdirectorio por usuario (opción n. ° 1):

Tenga en cuenta que:

los nombres de directorio (bajo keydir) no importan a gitolite.
el nombre del directorio debe ser universal único, como una dirección de correo electrónico o alguna otra ID global. Esto permite a los usuarios "git" con potencialmente el mismo nombre de usuario en diferentes hosts.
una clave como "user.pub" o "[email protected]" podría ser compartida por un usuario en varios hosts; sin embargo, se puede desalentar al hacer esto según la política.

En general prefiero y uso la opción n. ° 1, salpicada con algunos ejemplos de la opción n. ° 2. La opción n. ° 2 podría simplificar la automatización de la intranet si tiene servidores en funcionamiento (tal vez aprovisionando y reciclando máquinas virtuales) y desea mantener las cosas a nivel de host en lugar de a nivel de usuario, por lo que puede (por ejemplo) limpiar fácilmente obsoletos claves en un host fuera de servicio (por ejemplo, VM de prueba de corto plazo).

Lo bueno de gitolite es que la (re) organización del directorio keydir no afecta a los usuarios. Pero puede bloquear (inadvertidamente) a sus usuarios (o a usted mismo) si no tiene cuidado.

Instala gitolite bajo un usuario en el servidor; usualmente git , y en su cadena de conexión SSH, siempre usa explícitamente git@servername para conectarse a la cuenta de usuario de Git. Gitolite luego verá qué clave pública está ofreciendo, la encontrará en su configuración y lo tratará como si fuera el usuario asociado.

Para Gitolite v3 al menos la solución más fácil es utilizar el sistema de subcarpetas documentado aquí http://sitaramc.github.com/gitolite/users.html

Gitolite buscará recursivamente a través del teclado y asociará todos los .pub como un solo usuario. Estoy usando el sistema de subcarpetas ahora con un equipo portátil y una máquina de desarrollo de Linux y funciona bien.

La convención de usuario @ host parece demasiado complicada.

Estoy haciendo algo como esto:

Siempre te conectas así:

git clone gitoliteuser@gitoliteserver:reponame

no importa qué usuario eres. Gitolite lo identifica por la clave pública que está proporcionando. Esta clave se llama dave.pub, por ejemplo. Todo lo que se hace a través de una conexión ssh con esta clave pública, será analizado por gitolite de acuerdo con "dave" o "all" en el archivo de configuración.

Usted es libre de configurar el nombre y el correo electrónico para que sea lo que quiera en diferentes máquinas y repositorios diferentes. Los commits tendrán esa información. Pero qué rama, árbol o repositorios puede leer o escribir está dictado por cómo se restringe "dave" en el archivo de configuración en el repositorio de administrador, si usa la misma clave pública / privada para ssh.

Espero que esto ayude.