EPEL 저장소에서 Centos6.4로 gitolite3을 설치했습니다. 마음에 들지 않는 부분이 많아서 바꾸려고 노력했습니다. 먼저, 잘 알려지지 않은 gitolite3 사용자와 거리를 두기 위해 'git'이라는 추가 사용자 및 그룹을 생성했습니다. 둘째, /var/lib/gitolite3 대신 사용자 정의 폴더 /Server/Projects를 사용했습니다. 소유권과 권한이 동일한지 확인했습니다.
설정에도 문제가 없었습니다(su - git, 관리 클라이언트 키를 사용한 gitolite3 설정).
일반적으로 클라이언트 시스템에서 이 명령은 ssh git@myserver info저장소와 권한을 나열하는 멋진 gitolite 일반 반환을 생성합니다. 하지만 이제는 비밀번호를 요청합니다. 분명히 gitolite는 더 이상 이 사용자를 통해 ssh 포트에 연결되지 않지만 일반적인 bash는 연결됩니다.
저는 SSH 전문가가 아니기 때문에 문제가 발생했거나 해야 할 일을 잊어버렸습니다. 어디를 봐야 할까요? /usr/share/gitolite3/gitolite3-shell은 git 사용자와의 SSH 요청이 들어올 때 SSHD가 호출해야 하는 앱이라고 생각합니다.
답변1
SSH는 쉽지 않습니다. 나는 그것을 스스로 해결했지만 명확하지 않았습니다. 대부분 SELinux 문제였는데, pubkey도 제대로 설정하지 않은 것을 발견했습니다.
먼저, gitolite 서버를 관리할 로컬 컴퓨터에 대한 공개 키(admin.pub)를 (다시) 생성하고 이를 서버 git 사용자 홈 폴더에 복사한 다음 (홈 폴더의 git 사용자 아래에서) gitolite를 다시 실행합니다. 해당 공개키로 설정하세요. 여기서 참고할 점은 내 로컬 컴퓨터가 msys-git이 설치된 창이므로 문제가 쉽지 않다는 것입니다.
# su - git
$ cd /Server/Projects
$ gitolite setup --pubkey admin.pub
..Pubkey 문제가 해결되었습니다. selinux는 학습 곡선이 더 컸지만 기본적으로 복사만 하면 원래 /var/lib/gitolite3 폴더 컨텍스트 라벨이 모두 손실됩니다. semanage를 사용하여 라벨링을 복원하려면 현재 gitolite 폴더를 설정한 원래 폴더에서와 동일한 라벨링(-e 플래그 사용)을 참조합니다. 이는 기존 selinux 파일 컨텍스트에만 추가되므로 selinux 파일 컨텍스트에서도 이를 복원해야 합니다. 마지막 함정은 상대 경로가 아닌 절대 경로를 사용하는 것입니다. ll 명령으로 수행한 작업을 확인할 수 있습니다.
# semanage fcontext -a -e /var/lib/gitolite3 /Server/Projects
# restorecon -R /Server/Projects
# ll -aZ
이제 로컬 컴퓨터에서 공개 키가 나온 컴퓨터에서 아래 명령을 사용하여 모든 것을 시도해 보십시오. 제게는 효과적이었습니다. ssh git@unclefloserver info서버가 실제로 요청하는 사용자/컴퓨터 조합의 공개 키를 가지고 있는 경우에만 멋진 gitolite3 repo 정보 출력을 반환한다는 것을 몰랐습니다 . 나 또한 이 개념을 조금 이해하지 못했고, 다른 컴퓨터에서 이것을 시도하고 있었습니다.
> git clone git@server:gitolite-admin
압력을 유지해 준 @Etan Reisner에게 큰 감사를 드립니다.