개요

개요

저는 AWS에서 두 개의 우분투 인스턴스(pem 키를 사용하여 액세스)로 작업하고 있습니다.

두 인스턴스 모두에 대해 rsync를 설정했으며 ubuntu@ipaddress인 기본 사용자를 사용하면 작동합니다. 그러나 다른 사용자와 함께 rsync를 사용하려고 하면( 예를 들어 rsync 명령 앞에 입력 sudo su - jenkins하거나 심지어 입력 중임 ) 다음 오류가 발생합니다.sudo

Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.0]

내가 취한 단계:

으로 로그인한 동안 (ssh-keygen을 사용하여) ssh 키를 생성하려고 시도했고 jenkins이를 (rsync를 실행 중인 위치) 및 심지어 (거기서 rsync를 실행하려고 시도한 위치) authorized_keys모두의 파일 에 추가했습니다./home/ubuntu/.ssh/authorized_keys$JENKINS_HOME/.ssh/authorized_keys

Pem 키를 사용해 동일한 작업을 수행해 보았지만 작동하지 않았습니다.

내가 실행하려고하는 것은 다음과 같습니다.

rsync -avuh --delete -e ssh jenkins@ipaddress:/var/lib/jenkins/* /var/lib/jenkins

그리고 여기에 키 파일이 있습니다

rsync -avuh --delete -e 'ssh -i path/to/key.pem' [email protected]:/var/lib/jenkins/* /var/lib/jenkins

추신: 우분투 사용자와 함께 실행하고 싶지 않은 유일한 이유는 failed: Permission denied (13)많은 일을 하기 때문입니다(파일이 젠킨스의 소유이기 때문에).

최종 목표:

cronjob을 수행하여 기본 인스턴스와 함께 백업 jenkins 인스턴스를 지속적으로 백업하려고 합니다.

*/30 * * * * /usr/bin/rsync -avuh --delete -e ssh root@jenkinsprimary:/var/lib/jenkins/* /var/lib/jenkins

답변1

다음 2가지를 구별해야 합니다.

  • WHOSSH 연결을 설정합니다..
  • 어느원격 사용자가 파일을 소유합니다.복사하려는 항목입니다.

개요

(srcmachine)  (rsync)   (destmachine)
  srcuser    -- SSH -->   destuser
                             |
                             | sudo su jenkins
                             |
                             v
                          jenkins

rsync를 원한다고 가정해 보겠습니다.

  • 에서:
    • 기계:srcmachine
    • 사용자:srcuser
    • 예배 규칙서:/var/lib/jenkins
  • 에게:
    • 기계:destmachine
    • 사용자: destuserSSH 연결 설정.
    • 예배 규칙서:/tmp
    • 최종 파일 소유자: jenkins.

해결책

rsync --rsync-path 'sudo -u jenkins rsync' -avP --delete /var/lib/jenkins destuser@destmachine:/tmp

설명

     --rsync-path=PROGRAM    specify the rsync to run on the remote machine

요령은 SSH 연결을 설정한 사용자( )가 아닌 rsync다른 사용자( )와 함께 원격 시스템에서 실행하도록 지시하는 것입니다 .jenkinsdestuser

요구사항

SSH 액세스

(srcmachine)         (rsync)   (destmachine)
  srcuser           -- SSH -->   destuser

[~/.ssh/id_rsa]                [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside
[~/.ssh/id_rsa.pub]

다음 항목에 대한 권한을 제한하는 것을 잊지 마세요 ~/.ssh.

chmod 700 ~/.ssh

sudoerdestuser

destuser수 있는 특권이 있어야 합니다 sudo -u jenkins rsync.

destuser일반적으로 를 의 멤버로 설정합니다 sudoers. 이렇게 하려면 root@ 에서 다음을 수행합니다 destmachine.

cat > /etc/sudoers.d/destuser << EOF
destuser ALL=(ALL) NOPASSWD:ALL
EOF

이전에 테스트하려면 @ rsync에 로그인하여 다음을 실행하면 됩니다 .destuserdestmachine

sudo su jenkins
echo $USER

반환되는 경우:

jenkins

이는 귀하가 사용자로 로그인되었음을 의미하며 , 에스컬레이드 권한이 작동하기 때문에 jenkins귀하의 명령도 작동할 것임을 의미합니다 .rsyncjenkins

잘못된 해결 방법에 대한 참고 사항: 대상 사용자와 SSH 연결을 설정하세요.jenkins

그냥 이걸 해보는 게 어때요?

(srcmachine)         (rsync)   (destmachine)
  srcuser           -- SSH -->    jenkins

[~/.ssh/id_rsa]                [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside
[~/.ssh/id_rsa.pub]

jenkins"서비스" 계정이기 때문에 80외부 HTTP 액세스를 위해 포트(또는 그 이상)를 노출하는 서비스를 실행한다는 의미이며 액세스 권한을 얻기 위해 HTTP를 통해 Jenkins 서비스를 통해 보안 침해가 발생할 가능성이 있음을 의미합니다. .

그렇기 때문에 우리는 www-data다양한 서비스를 실행하는 사용자와 유사자를 보유하고 있습니다. 노출된 포트에서 해킹당하는 경우에는 할 수 있는 일이 별로 없습니다.

  • 모든 것이 읽기 전용입니다.
  • 에 쓰는 것을 제외하고 /var/log/THE_SERVICE.

따라서 사용자에게 SSH 액세스를 허용하면 jenkins표면 공격이 노출됩니다(따라서 SSH 액세스는 root!!로 표시됩니다).

root게다가 다른 사용자( , 등) 로 재동기화하려면 www-dataSSH 키 공개 키를 해당 계정에 복사해야 합니다(번거로움).

좋은 솔루션: 설정해야 합니다.사용자 계정에 대한 SSH 액세스는 가능한 한 적습니다.( destuser) 저것확대할 수 있음원하는 "서비스" 계정( jenkins, root등) 으로

답변2

다른 사용자로서 rsyncing과 비슷한 문제가 발생했습니다. 다음 명령을 실행하여 문제를 해결했습니다.

rsync -avu -e "ssh -i my-key -o StrictHostKeyChecking=no -l user-i-want-to-use-in-rsync" ./local_dir remote_host:remote-host-dir

다른 사용자로 rsync를 실행하려면 키를 조작해야 할 수도 있습니다.

답변3

sudo -u jenkins -i rsync ...

~와 함께따옴표 없음.

SSH 키 등을 포함한 사용자 환경에서 명령을 실행 -i시키는 옵션 입니다 .sudo.profile.bash_profile

남자 에게서 sudo:

-i, --login

대상 사용자의 비밀번호 데이터베이스 항목에 지정된 쉘을 로그인 쉘로 실행하십시오. 이는 .profile, .bash_profile또는 같은 로그인별 리소스 파일이 .login셸에서 읽혀진다는 것을 의미합니다. 명령이 지정되면 쉘의 옵션을 통해 실행할 수 있도록 쉘에 전달됩니다 -c. 명령이 지정되지 않으면 대화형 쉘이 실행됩니다. sudo쉘을 실행하기 전에 해당 사용자의 홈 디렉토리로 변경을 시도합니다. 명령은 사용자가 로그인할 때 받는 환경과 유사한 환경에서 실행됩니다. 대부분의 쉘은 대화식 세션과 비교하여 명령이 지정될 때 다르게 동작한다는 점에 유의하십시오. 자세한 내용은 쉘 설명서를 참조하세요. sudoers(5)매뉴얼 의 명령 환경 섹션에는 -isudoers 정책이 사용 중일 때 명령이 실행되는 환경에 옵션이 어떤 영향을 미치는지 설명되어 있습니다.

답변4

비슷한 문제가 있습니다.
cron을 사용하여 이 문제를 해결합니다. 하지만 cron은 특정 사용자(예: jenkins)로 실행되어야 합니다.

cron 작업을 수행하십시오.

$ crontab -u jenkins -e

그런 다음 필요에 따라 cron을 채우십시오.

*/2 * * * * sh /home/user/scp.sh 2>&1 >> /home/user/errmail.log

관련 정보