Niepowodzenie informacji Gitolite3 SSH

Zainstalowałem gitolite3 z repozytorium EPEL do Centos6.4. Było wiele rzeczy, które mi się nie podobały, więc postanowiłem je zmienić. Najpierw stworzyłem dodatkowego użytkownika i grupę o nazwie „git”, aby oddalić się od niejasnego użytkownika gitolite3. Po drugie, użyłem niestandardowego folderu / Server / Projects zamiast / var / lib / gitolite3. Upewniłem się, że własność i uprawnienia były takie same.

Instalacja również nie przebiegała bez problemu (su - git, następnie instalacja gitolite3 z kluczem klienta administratora).

Zwykle na komputerze klienckim polecenie ssh git@myserver infogeneruje niezły zwrot gitolite z listą repozytoriów i uprawnień. Ale teraz daje mi prośbę o hasło. Oczywiście gitolite nie jest już podłączony do portu ssh przez tego użytkownika, ale zwykle jest to bash.

Nie jestem ekspertem od SSH, więc coś poszło nie tak, albo zapomniałem coś zrobić. Gdzie powinienem szukać Myślę, że / usr / share / gitolite3 / gitolite3-shell to aplikacja, którą SSHD powinien wywoływać, gdy przychodzi żądanie SSH z użytkownikiem git.

— Florian Mertens
źródło

Jakie są uprawnienia dla katalogu .ssh i pliku .ssh / Author_keys dla użytkownika git? Co ssh -vvv git@myserver infomówi Co mówi dziennik ssh na serwerze?

— Etan Reisner,

Dzięki za pomoc! Czy lokalny użytkownik wykonujący to polecenie ssh musi być znany na liście autoryzowanych ssh git @ server? -vvv zwraca wiele informacji, czy chcesz to wszystko zobaczyć? Gdzie znajduje się dziennik ssh i czy pytasz o lokalny dziennik ssh lub dziennik sshd serwera?

— Florian Mertens,

Dziennik serwera. Tak, wszystkie dane wyjściowe. Klucz, którego używa użytkownik lokalny, musi znajdować się na liście kluczy autoryzowanych użytkownika git @ server, w przeciwnym razie klucz użytkownika lokalnego nie uwierzytelni użytkownika na koncie git (ale nie powinieneś nic z tym robić, ponieważ gitolite zarządza dla ciebie kluczami autoryzowanymi) ).

— Etan Reisner

SSH nie jest łatwe. Rozwiązałem to sam, ale nie było to oczywiste. Był to głównie problem z SELinuksem, ale okazało się, że nie ustawiłem również poprawnie klucza publicznego.

Najpierw utworzyłem (ponownie) klucz pub (admin.pub) dla komputera lokalnego, który miał administrować serwerem gitolite, skopiowałem go do katalogu domowego użytkownika git serwera, uruchom ponownie (pod użytkownikiem git w jego folderze domowym) gitolite skonfiguruj z tym kluczem pubowym. Należy zauważyć, że mój komputer lokalny to system Windows z msys-git, dzięki czemu problem nie jest łatwy.

# su - git
$ cd /Server/Projects
$ gitolite setup --pubkey admin.pub

..To rozwiązało problem z kluczem publicznym. Selinux był większą krzywą uczenia się, ale zasadniczo tracisz wszystkie oryginalne oznaczenia kontekstowe folderów / var / lib / gitolite3, gdy kopiujesz. Aby przywrócić oznaczenia (z semanage), należy odwołać się do tych samych oznaczeń (z flagą -e) jak w oryginalnym folderze, w którym ustawiono bieżący folder gitolite. Ponieważ to tylko dodaje do istniejących kontekstów plików selinux, musisz również przywrócić je z kontekstów plików selinux. Ostatnim pitholem jest użycie ścieżek bezwzględnych, a nie ścieżek względnych. Możesz zobaczyć, co zrobiłeś za pomocą polecenia ll:

# semanage fcontext -a -e /var/lib/gitolite3 /Server/Projects
# restorecon -R /Server/Projects
# ll -aZ

Teraz na lokalnej maszynie wypróbuj to wszystko za pomocą poniższej komendy z komputera, z którego pochodzi klucz pubowy, to zadziałało dla mnie. Zauważ, że nie wiedziałem, ssh git@unclefloserver infoże zwróci dobre wyjście informacji repo gitolite3, jeśli serwer faktycznie ma klucz pub żądającej kombinacji użytkownik / komputer. Nie zrozumiałem też trochę tej koncepcji i próbowałem tego z innego komputera.

> git clone git@server:gitolite-admin

Ogromne podziękowania dla @Etan Reisner za utrzymanie presji.

— Florian Mertens
źródło