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


153

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). 

답변:


182

언급했듯이 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_keysuser1@serverAuser2@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

1
정답입니다. 표시해야합니다.
Xealot

41
단지 작품의 경우 user2입니다 위 root! 그렇지 않으면 user2SSH_AUTH_SOCK가 올바르게 설정되지만 user2/ tmp / ssh-GjglIJ9337 /에 액세스 할 수 없습니다. root액세스 권한이 있습니다. 따라서이 문제의 일부를 해결 아닌 작전을 할 수 있습니다 : " 소켓 내 원래의 사용자 만이 읽을 수있다"
피터 V. Mørch

6
Defaults>root env_keep+=SSH_AUTH_SOCK그것은 단지 앞으로 sudoing 때 확인해야 루트. 보안상의 이유로 다른 사용자에게는 그렇게하고 싶지 않습니다. 다른 다른 에이전트에 대해 별도의 ssh-agent를 실행하고 적절한 키를 추가하십시오.
Paul Schyska

1
sudo su -저에게는 효과적이지 않습니다 sudo. 쉘 시작 시간이 아니기 때문에 환경을 보존 할 수 없을 것 입니다. sudo su작동하는 것 같습니다.
Alex Fortuna

3
왜 사람들이 sudo su어쨌든 사용하는지 이해하지 못했습니다 . 당신이 루트 쉘을해야하는 경우, 그 무엇 sudo -s이나 sudo -i입니다.
eaj

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

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


2
위의 주석과 마찬가지로 루트가되는 경우에만 문제를 해결합니다.이 경우 루트는 $ SSH_AUTH_SOCK에 대한 일반적인 액세스 권한을 얻을 수 있기 때문입니다.
doshea

35

허용 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$

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


6
이 방법 otheruser을 사용할 때 ssh 인증을 사용할 수 있는 다른 사용자도 로그인 하십시오.
gitaarik

이것은 "sudo su-otheruser"를 "sudo su otheruser"로 변경해야한다는 점을 제외하고는 작동합니다 (-제거).
Charles Finkel

1
rwx그렇지 않습니까 rw(또는 r전혀)?
anatoly techtonik

3
@anatolytechtonik From man 7 unix-Linux에서 소켓에 연결하려면 해당 소켓에 대한 읽기 및 쓰기 권한이 필요합니다. 또한 소켓을 작성하는 디렉토리에 대한 검색 (실행) 및 쓰기 권한이 필요하거나이 소켓에 연결할 때 검색 (실행) 권한 만 필요합니다. 따라서 위의 답변에서 소켓에 대한 실행 권한은 중복됩니다.
mixel

대신 당신이 사용할 수있는 / 등 /의 sudoers를 편집해야하는sudo -u otheruser --preserve-env=HOME -s

14

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

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으로 변경하면 더 안전 할 수 있습니다. 그러나 그룹을 변경하려고 할 때 "작업이 허용되지 않습니다"라는 메시지가 나타납니다.


6
이것은 매우 위험합니다. 다른 모든 사용자에게 SSH 에이전트 사용 권한을 부여하는 것은 모든 신임 정보를 제공하는 것과 같습니다 (sudo 또는 su를 사용하는 경우 시스템의 다른 모든 사용자와 ssh에 대한 모든 다른 사용자에게 루트 권한을 부여 함). . 이것은 절대로 끝나서는 안됩니다!
Matija Nalis

4
나는 "이것은 절대로해서는 안된다!"라는 말에 동의하지 않습니다. 이 위험이 허용되는 많은 경우가 있습니다. 예를 들어, 모든 사람이 동일한 권한을 가지고 있고 다른 모든 사용자를 신뢰하는 소규모 팀. 관련된 위험을 이해하지 않고서는 절대 안됩니다. 그러나 일단 이러한 위험이 이해되면 위험이 허용되는 경우가 있습니다.
phylae

6

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


그는 자신의 질문의 맨 아래에 언급하기가 어려울 것이라고 말했습니다.
Fahad Sadah

이것은 아마도 가장 좋은 해결책이지만 $ USER가 Real Person (tm) 인 경우 털이됩니다. – authorization_keys에서 SA의 키를 삭제하거나 암호를 변경할 수 있습니다.
voretaq7

당신은 authorized_keys에 (그들이 정말 플로리안 액세스를 거부 설정하는 경우, 그들은 그들이 자신의 디렉토리에있는, 삭제하고 다시 만들 수 있지만)에 자신의 쓰기 액세스를 제거 할 수 있습니다
파하드 Sadah

4

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

ssh -A otheruser@localhost

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

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


SSH 대신 otheruser비아 를 통해서만 액세스 할 수있는 경우에는 작동하지 않습니다 sudo(예 : SCP를 다음과 같이 원함 www-data)
Gert van den Berg

3

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


어떤 버전의 sudo가 있습니까? 내 (1.6.7p5, CentOS 4.8)의 맨 페이지에는 -i가 없습니다.
David Mackintosh

Sudo version 1.6.9p17데비안 레니에서 실행 중입니다. 시도 sudo -s?
Fahad Sadah

6
나를 위해 작동하지 않습니다.

Ubuntu에서 Sudo 1.8.9p5를 사용 sudo -s하거나 sudo -i나를 위해 일 하지도 마십시오 .
Jon L.

2

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

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패키지 를 설치해야 함 ).


1

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

sudo su - otheruser

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

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

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

sudo -E su otheruser

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


0

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

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


1
흠,하지만 ssh로이 작업을 수행하면 어쨌든 해당 사용자가 내 에이전트에 액세스 할 수 있습니까?

에이전트 전달을 통해 대상 사용자에게 SSH를 연결하면 에이전트 요청이 "실제"에이전트가있는 곳으로 체인을 반송합니다. 원래 사용자로부터 su 또는 sudo를 할 때 SSH 에이전트 소켓에 액세스 할 수 없거나 액세스하지 않아야합니다. 존재하는 디렉토리는 모드 700이며 원래 사용자가 소유합니다. (명백한주의 사항 : 루트로 전환하고 SSH_AUTH_SOCK 환경을 재설정하는 경우 작동 할 수도 있지만, 이에 의존하지는 않습니다.)
voretaq7

1
내 서버 (Ubuntu 12.04, ssh 버전 OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 2012 년 3 월 14 일)에서 ssh -a-A인수가 있습니다. -a의도 한 것과 정확히 반대되는 경우 에이전트 전달을 비활성화합니다. 따라서 최신 (및 가능한 모든) 버전의 Ubuntu에서 -A에이전트 전달을 활성화 하는 데 사용하십시오.
knite

@knite 당신은 정확합니다-그것은 내 대답에 (3 세!) 오타입니다. 지금 수정 :-)
voretaq7
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.