Gitolite usernames in authorized_keys file

Question

I will try to explain my scenario in the best way:

I use gitolite on a debian squeeze server and there are 3 users who can access and work with repositories:

• alex@workbox
• alex@homebox
• katy@workbox

Above are the corresponding usernames and host names from the three Ubuntu mailboxes (Alex works from two places).

The first thing I did was add alex@workbox to the gitolit:

• Alex created his ssh key using ssh-keygen
• I copied my ssh key as [e-mail] to the "keydir" folder of my local cloned gitolite-admin repository
• Modified conf / gitolite.conf file of my local cloned repository gitolite-admin to allow alex @workbox RW to access the repository:
  repo project1
RW+ = alex@workbox
• Was it ordinary:
  • git add .
  • git commit -m "Added alex@workbox "
  • git push

When Alex attempted to clone the project1 report, an error occurred stating that access for user alex was denied.
So, I logged in to the server and opened /var/lib/gitolite/.ssh/authorized_keys .
The first part of the file:

 command="/usr/share/gitolite/gl-auth-command alex",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa... 

So, I manually replaced alex with alex@workbox , saved the file, and this time Alex was able to clone the repository and work with it without any problems.

Then I took the same steps above to add Katie, and after clicking on gitolite-admin I again opened the authorized_keys file and saw that the guitarit replaced " user@hostname " with " user ".
So he is alex instead of alex@workbox and the same for katy .
Then I had to manually replace this and save the file. I saw that for every click I make for gitolite-admin repo gitolite replaces each " user@hostname " with " user " in its .ssh/authorized_keys and thus makes repositories inaccessible to users.

How can I make gitolite save " user@hostname "? Is there a configuration on the server or a configuration change on my local cloned gitolite-admin repo?

Answer 1

Syntax :

Usernames and repo names are as simple as possible; they must begin with an alphanumeric, but after that they may also contain . , _ or - .

Usernames can be followed by @ and domainname containing at least one . (this allows you to use the email address as the username).

Your naming convention does not match the correct syntax for the presence of " @ ".

This rule can be seen in action in src/triggers/post-compile/ssh-authkeys

 sub optionise { my $f = shift; my $user = $f; $user =~ s(.*/)(); # foo/bar/baz.pub -> baz.pub $user =~ s/(\@[^.]+)?\.pub$//; # baz.pub, [e-mail] -> baz my @line = slurp($f); if ( @line != 1 ) { _warn "$f does not contain exactly 1 line; ignoring"; return ''; } chomp(@line); return "command=\"$glshell $user" . ( $kfn ? " $f" : "" ) . "\",$auth_options $line[0]"; } 

Answer 2

You really don't need to directly modify the Gitolite section of authorized_keys .

The idea of ​​adding @suffix to @suffix key keys is that it allows the administrator to easily add multiple keys for a single Gitolite user. In your case, keydir/ [e-mail] and keydir/ [e-mail] both mapped to the same Gitolite user named alex . This is usually what you want if both of these keys belong to the same person; it allows you to use alex in the configuration file instead of mentioning the names of both keys. If these keys belong to other people (or you want to apply different access restrictions for people of different keys), you will need to name them a little differently (use a separator other than @ , or include at least one period between @ and .pub ).

Multiple keys per user

A section of the Gitolite documentation called “multiple keys for each user” describes how to configure multiple keys for a single Gitolite user. There are two main ways:

• put the files named username.pub in different keydir subdirectories (newer method),
• add the suffix @ after the username (an older method that is sometimes difficult to add Gitolite administrators to).

Using the subdirectory method, you should use the following paths:

 keydir/workbox/alex.pub keydir/homebox/alex.pub 

Using the suffix method, you should use the following paths:

 keydir/ [e-mail] keydir/ [e-mail] 

All the paths listed above contain keys that will be authenticated as a Gitolite user with the name alex (no @ in the username); you must use (for example) RW+ = alex in the configuration file. These methods (only using part of the key name to form the Gitolite username) allow the administrator to add (and delete) the keys for Gitolite users without having to edit the configuration file every time someone wants to use a new key (or lose access to (or control ) of the old key).

For example, if alex receives a new mobile device, you can add keydir/mobile/alex.pub or keydir/ [e-mail] to give this key access to everything that alex can already access.

Email-style usernames

There is a restriction on the suffix method: the suffix must not contain a period. This limitation exists, so you can use email addresses as usernames; you can use suffixes (or subdirectories) with these usernames. The following key paths can be used to provide keys for the username [e-mail] ( @gmail.com is part of the username):

 keydir/external/ [e-mail] keydir/ [e-mail] @remotebox.pub 

This user [e-mail] is different from the regular user jane .

Note: by manually adding the @workbox suffix to the authorized_keys entry, you actually forced Gitolite to use an email type username that did not have a period (depending on how keydir key names are processed in usernames, this is usually not possible).

What to use?

It seems that the subdirectories make the most sense when you expect that you can approach your user keys in a limited number of categories (home, work, mobile devices, etc.). @ Suffixes seem useful to you if you have one-time keys that don't fit in any particular category.

Regardless of the subdirectory / suffix, email-style usernames can be useful for those who otherwise do not have a canonical username within your organization (for example, a temporary external contractor).

Summary

Gitolite usernames are derived from the paths in keydir , but they are not identical to the file names that are used there. In particular, keydir path names keydir mapped to usernames by deleting any subdirectories and removing the .pub extension along with any @ suffixes (until there is a period after @ - otherwise, @ is treated as part of the email-style username).

If you have a situation where one person wants to use several keys, then you should probably use one of the above methods (subdirectories or @ suffix (no period)) so that you can match multiple keys with a single Gitolite username.

Example: install keydir/workbox/alex.pub and keydir/homebox/alex.pub , then use alex in the configuration file (providing equal access to both keys).

If you have keys for different people to whom you want to give similar names, or you want to allow different access for individuals with different keys (is home access read-only?), You must use a separator other than @ between the distinguishing parts of the username (or make sure there is a period after @ , so it is treated as an email-style username).

Example: install keydir/workbox/alex.pub , keydir/homebox/alex-ro.pub and mobile/alex-ro.pub , then use alex and alex-ro in the configuration file (for example, in some way that gives access alex-ro read-only, and alex gets read and write access).