#6 closed task (fixed)

Investigate how git SSH login are working

Reported by: mbooth Owned by: mbooth
Priority: major Milestone: Ansible Migration Leftovers
Component: service: git Keywords:
Cc:

Description

We forgot how gitolite works -- when we were playing with it, we deleted Caolan's SSH key from the LDAP and he was still able to clone repos, etc.

:-o

For background I configured gitolite to check in the LDAP for SSH keys for authenticating git requests, but I guess it may be some kind of caching or other cleverness.

For peace of mind, please investigate what exactly is going on there.

Change History (7)

comment:1 Changed 19 months ago by mbooth

Owner: changed from somebody to mbooth
Status: newassigned

I implemented this, so maybe I will look at it -- just need to page all the context back into my head.

comment:2 Changed 19 months ago by mbooth

Milestone: Ansible Migration Leftovers

comment:3 Changed 19 months ago by mbooth

Type: defecttask

comment:4 Changed 19 months ago by mbooth

Component: miscgit

comment:5 Changed 19 months ago by mbooth

Okay here's how my testing went:

New user created, no pubkey added to LDAP yet

$ git clone mbooth_test@git.darkpeak.org:testing.git
Cloning into 'testing'...
mbooth_test@git.darkpeak.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Since auth was denied, no home directory was created on the server.

Add a pubkey for the user in LDAP

$ git clone mbooth_test@git.darkpeak.org:testing.git
Cloning into 'testing'...
warning: You appear to have cloned an empty repository.

And a home directory was created on the server:

# ls -al /home/mbooth_test/
total 44
drwxr-xr-x  6 mbooth_test mbooth_test 4096 Jul 20 13:31 .
drwxr-xr-x 13 root        root        4096 Jul 20 13:30 ..
-rw-r--r--  1 mbooth_test mbooth_test  220 Jul 20 13:30 .bash_logout
-rw-r--r--  1 mbooth_test mbooth_test 3526 Jul 20 13:30 .bashrc
drwxr-xr-x  6 mbooth_test mbooth_test 4096 Jul 20 13:30 .gitolite
lrwxrwxrwx  1 mbooth_test mbooth_test   26 Jul 20 13:30 .gitolite.rc -> /etc/gitolite3/gitolite.rc
drwxr-xr-x  3 mbooth_test mbooth_test 4096 Jul 20 13:30 local
-rw-r--r--  1 mbooth_test mbooth_test  397 Jul 20 13:30 mbooth_test.pub
-rw-r--r--  1 mbooth_test mbooth_test  675 Jul 20 13:30 .profile
-rw-r--r--  1 mbooth_test mbooth_test   12 Jul 20 13:31 projects.list
drwxr-xr-x  4 mbooth_test mbooth_test 4096 Jul 20 13:30 repositories
drwx------  2 mbooth_test mbooth_test 4096 Jul 20 13:30 .ssh

The *.pub file here is pulled from the LDAP and the gitolite setup is executed with this key.

That key will be added into your gitolite-admin repo as "keydir/<user>.pub"

Gitolite then creates the .ssh/authorized_keys file, containing all the pubkeys from the keydir of your gitolite-admin repo.

Remove pubkey from the user in LDAP

Cloning and pushing etc still works even if you remove your pubkeys from the LDAP.

This is because of the combined behaviour of SSHD and gitolite:

  • Even though SSHD is configured to pull pubkeys from the LDAP, if none of the returned keys work to auth the user (or no keys are returned) SSHD will fallback to using the .ssh/authorized_keys file in the usual way.
  • Even though you deleted your key from LDAP, there is no communication back to gitolite to tell it so and gitolite will continue generating the .ssh/authorized_keys with all the pubkeys it has in the gitolite-admin repo.
  • Having SSHD fallback to the gitolite generated .ssh/authorized_keys file allows to give us the ability to grant access to our repositories to people who are external to Dark Peak.

To fully remove access with a key, one must both update it in the LDAP and update your keydir/<user>.pub file.

comment:6 Changed 19 months ago by mbooth

Status: assignedaccepted

comment:7 Changed 19 months ago by mbooth

Resolution: fixed
Status: acceptedclosed

Phew

Note: See TracTickets for help on using tickets.