☰

일반 사용자의 SSH 키를 사용하지만 모든 명령(예: git)에 대해 sudo 파일 권한을 갖는 방법

tag-icon • tag-icon files permissions sudo git
일반 사용자의 SSH 키를 사용하지만 모든 명령(예: git)에 대해 sudo 파일 권한을 갖는 방법

다음과 같이 프로젝트를 복제할 수 있습니다.

$ git clone [email protected]:root/myproject.git ~/bla

하지만 이제는 그것을 복제하고 싶습니다 /var/www.

$ git clone [email protected]:root/myproject.git ~/var/www

하지만 안타깝게도 글을 쓸 권한이 없습니다 /var/www. Sudo가 구하러 옵니다!

$ sudo git clone [email protected]:root/myproject.git ~/var/www
Cloning into 'www'...
[email protected]'s password:

이건 뭐죠? 비밀번호를 묻는 메시지가 표시되나요? 냄새 나는 비밀번호는 필요하지 않습니다!

분명히 요청과 함께 루트 사용자의 SSH 키를 보내고 있는데 해당 키를 git 저장소로 가져오지 않았기 때문에 거부됩니다. 과거에 내 솔루션은 폴더에 대한 권한을 일시적으로 변경하거나 먼저 액세스할 수 있는 위치에 복제한 다음 sudo를 사용하여 이동하는 것이었지만 올바른 방법을 배우고 싶습니다.

그렇다면...일반 ​​사용자의 ssh 키와 함께 sudo 파일 권한을 사용하여 git을 어떻게 사용합니까?

답변1

ssh실행 중인 에이전트가 있는 경우 다음을 수행합니다.

sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...

이는 기본적으로 git이 명령으로 시작된 명령 root(또는 ssh이 명령으로 시작된 명령 git)에 프록시를 사용하도록 지시합니다( 모든 권한이 있으므로 ssh연결할 수 있어야 함).root

실행 중인 SSH 에이전트가 없으면 미리 시작할 수 있습니다.

eval "$(ssh-agent)"

(그리고 필요에 따라 추가 키를 사용하십시오 ssh-add).

또는 다음을 사용할 수 있습니다.

sudo -E git clone...

통과하다모든환경 변수 sudo는 $SSH_AUTH_SOCK.

저 할 수 있어요아니요댓글에서 @NgOon-Ee가 제안한 대로 목록 $SSH_AUTH_SOCK에 추가되었습니다 env_keep. 일반적으로 root서비스를 시작한 사용자는 환경을 오염시키고 싶지 않습니다 . 예를 들어 sudo sshd, 서비스를 시작한다는 것은 해당 서비스를 통해 시작된 모든 세션이 사용자 환경을 상속하고 사용할 수 없고 사용해서는 안되는 것으로 사용자 환경을 오염시킨다는 것을 sshd의미합니다 . 대상 사용자가 인증 프록시를 사용할 수 없으므로 대상 사용자가 아닌 대상 사용자에 대해서도 이 변수를 전달할 필요가 없습니다.ssh$SSH_AUTH_SOCKroot

이제 이는 키 인증 문제만 해결합니다. root의 설정 도 상속하려는 경우 환경 변수를 사용하여 이를 수행 ~/.ssh/config할 수는 없지만 ssh에서는 가능합니다 git. 예를 들어 sugit함수를 다음과 같이 정의합니다.

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec ssh -o IdentityAgent='$SSH_AUTH_SOCK' \
             -o User=$LOGNAME \
             -F ~$LOGNAME/.ssh/config" git "$@"
}

즉, 루트 대신 SSH 프로필, 프록시 및 사용자 이름을 사용 git하도록 명령에 지시합니다.ssh

또는 원래 사용자로 실행하도록 지시하는 것이 더 좋습니다 git.ssh

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec sudo -Hu $LOGNAME SSH_AUTH_SOCK='$SSH_AUTH_SOCK' ssh" git "$@"
}

답변2

파일을 실행하는 사용자가 중요한 파일(또는 소켓)을 읽을 수 없는 경우 sudo파일(또는 소켓) 권한이 복잡해질 수 있습니다 . 여기에는 root파일이 root권한 없이 네트워크 공유에 있는 경우나 홈 디렉터리가 암호화되어 root액세스가 다시 거부될 경우도 포함됩니다.

확장 ACL을 지원하는 Unix 시스템에 대한 또 다른 접근 방식은 확장 ACL을 사용하는 것입니다. 이 경우 일반적인 기본 권한 외에 추가 쓰기 액세스 권한을 부여합니다.

$ sudo chown apache:www /var/www/html
$ sudo chmod g+s /var/www/html
$ sudo setfacl -m g:webedit:rwx /var/www/html
$ groups
jdoe webedit
$ ls -ld /var/www/html
drwxrwsr-x+ 4 apache www 25 Nov 21 19:42 /var/www/html
$

webedit하지만 그룹에 권한이 있으므로setfacl

$ git clone ~/repo /var/www/html
Cloning into '/var/www/html'...
done.
$ ls -al /var/www/html
total 0
drwxrwsr-x+ 4 apache www   25 Nov 21 19:42 .
drwxr-xr-x  4 root   root  31 Oct 19 20:39 ..
drwxrwsr-x  3 jdoe   www   14 Nov 21 19:42 a
drwxrwsr-x  8 jdoe   www  152 Nov 21 19:42 .git
$

그러나 확장 ACL에는 백업 소프트웨어가 확장 ACL을 처리하는 방법 확인 등 다양한 문제가 있습니다.

관련 정보