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

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

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

내가 생각할 수 있는 유일한 방법은 otheruser의 authenticate_keys 및 "ssh otheruser@localhost"에 내 키를 추가하는 것이지만, 모든 사용자와 서버 조합에 대해 수행하는 것은 번거로운 일입니다.

간단히 말해서:

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

답변1

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

하지만 다행스럽게도 구성이 매우 가능합니다. NET 의 구성 옵션 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@serverAuser2@serverBserverA/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

답변2

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

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

답변3

허용하다다른 사용자$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$

루트가 아닌 사용자에게도 더 안전하고 작동합니다.

답변4

sudo를 사용하는 대신 에이전트 전달을 통해 언제든지 localhost에 ssh를 통해 연결할 수 있습니다.

ssh -A otheruser@localhost

단점은 다시 로그인해야 한다는 것인데, screen/tmux 탭에서 사용하는 경우에는 한 번만 하면 됩니다. 그러나 서버와의 연결을 끊으면 소켓이 (물론) 다시 깨집니다. . 따라서 screen/tmux 세션을 항상 열어 둘 수 없다면 이상적이지 않습니다(그러나 SSH_AUTH_SOCK괜찮다면 환경 변수를 수동으로 업데이트할 수 있습니다).

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

관련 정보