ssh-agent 전달 및 다른 사용자에게 sudo

ssh 키로 로그인 할 수있는 서버 A가 있고 "sudo su-otheruser"기능이있는 경우 env 변수가 제거 되고 소켓은 원래 사용자 만 읽을 수 있기 때문에 키 전달이 손실됩니다 . "sudo su-otheruser"를 통해 키 전달을 연결할 수있는 방법이 있습니까? 그래서 전달 된 키 (필자의 경우 git clone 및 rsync)로 서버 B에서 작업을 수행 할 수 있습니까?

내가 생각할 수있는 유일한 방법은 otheruser 및 "ssh otheruser @ localhost"의 authorized_keys에 내 키를 추가하는 것입니다. 그러나 이것이 내가 가질 수있는 모든 사용자 및 서버 조합에 대해 번거로운 작업입니다.

한마디로 :

$ sudo -HE ssh user@host
(success)
$ sudo -HE -u otheruser ssh user@host
Permission denied (publickey). 

언급했듯이 sudo보안상의 이유로 환경 변수는에 의해 제거됩니다 .

그러나 다행스럽게도 sudo구성 할 수 있습니다 . 의 env_keep구성 옵션 을 통해 유지하려는 환경 변수를 정확하게 알 수 있습니다 /etc/sudoers.

에이전트 전달의 경우 SSH_AUTH_SOCK환경 변수 를 유지해야 합니다. 이렇게하려면 /etc/sudoers구성 파일을 편집하고 (항상 사용 visudo) env_keep옵션을 적절한 사용자로 설정하십시오 . 모든 사용자에 대해이 옵션을 설정하려면 다음 Defaults과 같은 행을 사용하십시오 .

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers 상세 사항은.

이제 (제공 같은 것을 할 수 있어야 user1'에 존재하는 공개 키를 ~/.ssh/authorized_keys에 user1@serverA와 user2@serverB,와 serverA의 /etc/sudoers파일은 위에 표시된대로 설정입니다) :

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

sudo -E -s

• -E는 환경을 보존합니다
• -s는 명령을 실행하고 기본값은 쉘입니다.

그러면 원래 키가 여전히로드 된 루트 셸이 제공됩니다.

허용 otheruser 에 액세스 할 $SSH_AUTH_SOCK파일을 그것은 그들로 전환하기 전에, 올바른 ACL에 의해, 예를 들어, 디렉토리입니다. 이 예는 호스트 컴퓨터 Defaults:user env_keep += SSH_AUTH_SOCK에서 가정 /etc/sudoers합니다.

$ ssh -A user@host
user@host$ setfacl -m otheruser:x   $(dirname "$SSH_AUTH_SOCK")
user@host$ setfacl -m otheruser:rwx "$SSH_AUTH_SOCK"
user@host$ sudo su - otheruser
otheruser@host$ ssh server
otheruser@server$

더 안전하고 루트가 아닌 사용자에게도 효과적입니다. ;-)

나는 이것이 또한 효과가 있음을 발견했다.

sudo su -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

다른 사람들이 지적했듯이, 전환하려는 사용자에게 $ SSH_AUTH_SOCK (루트 이외의 거의 모든 사용자)에 대한 읽기 권한이 없으면 작동하지 않습니다. $ SSH_AUTH_SOCK 및 777 권한이있는 디렉토리를 설정하여이 문제를 해결할 수 있습니다.

chmod 777 -R `dirname $SSH_AUTH_SOCK`
sudo su otheruser -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

그러나 이것은 매우 위험합니다. 기본적으로 시스템의 다른 모든 사용자에게 SSH 에이전트 사용 권한을 부여합니다 (로그 아웃 할 때까지). 그룹을 설정하고 권한을 770으로 변경하면 더 안전 할 수 있습니다. 그러나 그룹을 변경하려고 할 때 "작업이 허용되지 않습니다"라는 메시지가 나타납니다.

에 대한 권한이 있으면 $ USER의 홈 디렉토리에 유효한 공개 키를 사용 sudo su - $USER하여 ssh -AY $USER@localhost대신 대신 권한을 부여 할 수있는 좋은 주장이있을 수 있습니다 . 그런 다음 인증 전달이 수행됩니다.

sudo를 사용하는 대신 항상 에이전트 전달을 사용하여 localhost에 ssh를 사용할 수 있습니다.

ssh -A otheruser@localhost

단점은 다시 로그인해야한다는 것입니다. 그러나 화면 / tmux 탭에서 사용하는 경우 한 번의 노력만으로도 서버에서 연결을 끊으면 소켓이 다시 끊어집니다. . 따라서 화면 / tmux 세션을 항상 열어 둘 수없는 경우에는 이상적이지 않습니다 (단, SSH_AUTH_SOCK멋진 경우 환경을 수동으로 업데이트 할 수 있음 ).

또한 ssh 전달을 사용하는 경우 root는 항상 소켓에 액세스하고 ssh 전달로 로그인 한 경우 ssh 인증을 사용할 수 있습니다. 따라서 루트를 신뢰할 수 있는지 확인하십시오.

사용하지 말고 sudo su - USER오히려 사용하십시오 sudo -i -u USER. 나를 위해 작동합니다!

다른 답변의 정보를 결합하여 내가 생각해 낸 것 :

user=app
setfacl -m $user:x $(dirname "$SSH_AUTH_SOCK")
setfacl -m $user:rwx "$SSH_AUTH_SOCK"
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" -u $user -i

sudoers파일 을 편집 할 필요가 없기 때문에 이것을 좋아 합니다.

Ubuntu 14.04에서 테스트되었습니다 ( acl패키지 를 설치해야 함 ).

귀하의 명령에 따라 -(대시) 옵션에 문제가 있다고 생각 su합니다.

sudo su - otheruser

su 의 매뉴얼 페이지를 읽으면 옵션 -, -l, --login이 로그인 환경으로 쉘 환경을 시작 한다는 것을 알 수 있습니다 . 이것은 otheruser당신이 실행하는 env 변수 에 관계없이 환경입니다 su.

간단히 말해 대시는에서 전달한 모든 내용을 손상 sudo시킵니다.

대신이 명령을 시도해야합니다.

sudo -E su otheruser

@ joao-costa가 지적했듯이 -E실행 한 환경의 모든 변수를 보존합니다 sudo. 그런 다음 대시없이 su해당 환경을 직접 사용합니다.

불행히도 다른 사용자에게 su하거나 sudo를 사용하면 전달 된 키를 사용할 수 없게됩니다. 이것은 보안 기능입니다. 임의의 사용자가 ssh-agent에 연결하고 키를 사용하는 것을 원하지 않습니다. :)

"ssh -Ay $ {USER} @localhost"방법은 약간 번거롭지 만 (데이빗의 대답이 파손되기 쉽다는 의견에서 언급했듯이) 아마도 최선의 방법 일 것입니다.